ayanova/devdocs/todo.txt

@@ -74,36 +74,11 @@ TODO: MAIN GRID LIST ANALYSIS, DESIGN AND COMPLETION KEEPING IN MIND TTM
 				 	- That was easy to grasp in v7...hmm...
 			- CLIENT for selective ops only, for any feature that is going to commonly be required to use against *all* records it should be a defined route at the server and the server should handle it when client triggers (i.e. something like GDPR wiping of all client data etc)
 
-	- COLUMNS DISPLAYED
-		- Crtical columns are the name or equivalent that is unique as the primary item
-		- Other columns that are critical would be any that are stock and required
-		- Leaning toward static fixed column display that is sortable
-		- Not seeing any real reason to have many columns other than for viewing purposes and filtering which can be done outside of the grid
-		- IDEA: if I have a kick ass display format template builder that people can use easily then they can just decide which fields in which order to use for the "Name" field and then no need to include other columns, they can just define them for normal display
-			- Going to need this as a feature anyway, was previously for picklist selection in forms, but would apply to main grids as well.
-		- IDEA: right now on narrow window the name collapses into multiple rows as it tries to cram all fields into display
-			- Remove / add fields depending on view port width
-				- So minimum is the name and it expands outwards from there with stock required fields given priority
-				- A maximum is also set that beyond which it doesn't add any more columns so there is lot's of clean whitespace around it
+	
+
+
+	
 
-	- Should users be able to set columns or am I really going to force it to a preset?
-			- I had a customer today request the Description field from unit show in the workorder service grid, it doesn't do that
-			- Customers probably want the option of picking what fields show and what don't
-			- they will also want to set the order, maybe that's not going to be supported though
-			- Need to think this over, do I have defined columns or is the list just for display to select the record in which case can it just be one column with user selected values showing??
-			- Security and business rules may affect this as well, for some users they have rights to some of the record but not all of it, i.e. subcontractor so we do need granular field level control over what goes out from the server and at the client expectations
-			- 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.
-	- Main list hidden fields in edit form should not show in main grid either? 	
-		- overlaps with the user selectable stuff immediately above here
-		- Test with widget serial field as before
-	- FILTERS
-		- ??A cool feature might be built in filters for common date things so no need to make a "this quarter" filter it would just be there as a selectable filter option
-			- Although it might just pollute the list when the user just wants some basic ones they deem important
-		- ??what if a filter also had a selectable default sort order so whenever you picked that filter it also set the sort to what was chosen, however user could still click on visible column headings to change sort?
-			- But then what about hidden fields set to sort that user is not aware of and fight with the header clicks they make?
-	- Sorting
-		- V7 can sort by up to 3 columns which makes it possible to do something like sort all customers together then by date or something
 	
 	
 
@@ -126,6 +101,8 @@ TODO: MAIN GRID LIST ANALYSIS, DESIGN AND COMPLETION KEEPING IN MIND TTM
 			- This way can plunk it in different list forms and then wrap it with what is unique to that form and type etc
 			- This will be helpful also down the road for reporting stuff when that comes up as a source of copy-pasta
 			- USE MOCK column definition at the server end for now so can do client dev right up to functioning grid *then* go back and do the server template and column definition stuff for real
+			- MUST HANDLE HIDDEN FIELDS AND NOT DISPLAY (this is also a server issue)
+			- Grid does *NOT* have sort indicators or controls, that's behind the grid in the filter UI, this is necessary for reasons I forget 
 
 	- AFTER working mocked grid
 		- DISPLAY FORMAT TEMPLATES