ayanova/devdocs/todo.txt

@@ -46,23 +46,33 @@ CURRENT TODOs
 =-=-=-=-=-=-=
 
 
-TODO: HELP LINKS
-	- OBJECTIVE: start filling in help now so don't need to do it all later in one big push
-	- Make sure each form has a unique help link and also make a stub page in the documentation for that help link to be filled in later or now if applicable
-	- Make up the widget help doc and it should in turn have many links to individual features of the forms in general so can use those for other forms later
-		- i.e. anything that would be useful to know about the form and the features on it
 	
 
 
 TODO: FORM CUSTOMIZATION FORM	
-	- If a user changes a field data type there needs to be a big warning before accepting it.
-	- ACTIONABLE - How to handle custom field TYPE changes when they have data?
+		- ACTIONABLE - How to handle custom field TYPE changes when they have data?
 		- test scenario where a custom field type is changed, how does it react, what code changes are required
 		- I was leaning towards *not* mass changing the underlying records at the server when a type changes only because users may accidentally make a change and then want to reverse it before any records are affected.
 			- However this means the client needs to deal with incompatible data
 			- POTENTIAL FIX: Maybe the server should "vet" custom field data when it's about to send it out to the client and if it detects an invalid value it scrubs it for that record at that moment in time before it sends it off
 				- This way the client is always working with the correct data and also no mass changes are made at the server and if the user chooses not to save the record at the client then nothing is affected
 				- Maybe a function that all customfield able objects call?
+			- POTENTIAL FIX: Or maybe the Client is responsible for checking if any data incoming is compatible with the type and if not then co-erce it or clear if can't be co-erced
+				- CURRENT TEXT fields could handle any data so they don't need to be changed
+				- CURRENT BOOL fields can only handle empty or true false so they would need to be set null
+				- CURRENT TIME, DATE, DATETIME are pretty specific but all use a datetime string so any value not datetime like should be nulled
+				- CURRENT NUMBER, CURRENCY are also pretty specific but easy to identify if not fully numeric and then sb nulled or attempt to convert then null if not
+					- i.e. maybe someone has a text field where they entered $45.00 and wants to make it a currency instead, it should be able to extract the 45.0
+					
+
+
+TODO: AUTO-LOGOUT EXPIRED SESSION?
+	- first off, is this really an issue?
+	- Right now a user can simply close the browser in the middle of a session, re-open it any amount of time later and it will just keep working, however it might have outdatd cached data from the server
+	- What about a time limit after which a session needs to login again just to protect the users from themselves?
+	- Perhaps it can detect a full page refresh (which is what a restart essentially is) and see how long ago it was last active, maybe the time of the last API call to the server and use that info to force re-login.
+
+
 
 TODO: MAIN GRID LIST ANALYSIS, DESIGN AND COMPLETION
 	- Main grid time is off from edit form time by -1 hour