ayanova/devdocs/todo.txt

@@ -50,6 +50,9 @@ TODO: Custom fields component
 	- Add code to coerce the value or handle a completely change of datatype on the record
 		- i.e. it was text and now is a date etc
 
+TODO: Change detection dirty tracking not quite right on the widget form:
+	- Make a new record then click into each field and edit it and notice the save button doesn't enable
+	- But, if you tab between controls it *does* enable so somehow it's not firing a change event or something
 
 TODO: Error handler is not recognizing the same error over and over again and it should stop after so many dev errors
 	
@@ -139,6 +142,14 @@ TODO: save and new button in edit form like v7? Or only from main?
 
 RETEST HERE ON ALL DEVICES
 
+TODO: 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?
+
 TODO: Clean up TODO list, have only actionable, not completed items.
 	- Make a to_test.txt doc so can move todo's to to test doc for testing
 	- anything in this doc that isn't related directly to individual todo's other than a small big picture stuff at top sb elsewhere
@@ -214,6 +225,9 @@ TODO: INVESTIGATE - Grid / LIST VIEW COLUMNS SELECTABLE?? I know customers will
 	- Maybe list objects also return a list of fields the current user will expect to see so the list can be pre-set up with the columns at the client *then* the data fetched to populate the list
 	- Server should not send fields that are restricted or have them blocked out or something.
 
+
+
+
 TODO: List view FILTER button 
 	- Get it working
 TODO: Grid list STUB OUT other options