ayanova/devdocs/todo.txt

@@ -45,43 +45,15 @@ CURRENT ROADMAP
 CURRENT TODOs
 =-=-=-=-=-=-=
 
-TODO: Widget edit form start and end date are required by server but not set to required in the form template?!
+TODO: Widget edit form If not custom fields are visible then don't show the title of the section
 
-TODO: Form customization 
 
-		- When go to save then synthesize the record to send back
-		- SAVE
-			- Update the Store on success		
-			- Do not add any custom fields not set to be displayed, their mere presence in teh template means they are to be displayed 
-			- POST vs PUT?  Is post ever appropriate?  Shouldn't every form have a custom if it can already and if it's fetched and doesn't exist make one?
-				- Maybe need to modify the db init code in server to also create formCustom for every possible formCustom object and then only have a PUT route, no post?
-				- Perhaps GET route will create one automatically if it's something that should exist but doesn't and return that? Dynamically?
-					- Saves data storage for unused forms, but really that won't be shit anyway so...?
 
 
 TODO: HELP LINKS
 	- 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
 
-TODO: FORM CUSTOMIZATION FORM
+TODO: FORM CUSTOMIZATION FORM	
-	- Customize option on every form if user is logged in with BizAdminFull rights
-	- When customize is selected a generic form pops up with a list of fields provided by the backend and their current settings and controls
-            - This form can then be re-used everywhere as it's a stock object and this way we don't need to have a customize form for every existing CRUD form
-    - Choosing to expose one or more of up to 16 custom fields on form in custom field section that shows when at least one is enabled
-    - NO ability to edit localized text here, that's a separate central UI thing.
-        - Yes, v7 allows editing of lt in a form but I've decided to focus on one thing for this and not confuse it    
-    - Set whether a field is visible or not to user
-        - Some stock fields will never be able to be hidden, they will be "core" fields required for AyaNova operations and will have their hidden checkbox grayed out
-    - Set whether a field custom or stock is required to have a value entered or have it's value changed
-        - If required then it's like a business rule and treated just like that at the back and front end
-        - During business rule validation check at backend it checks if the fields are required and have entries and returns a validation error if not exactly the same as for built in rules        
-	- Do before main grid stuff below
-	- Where is it exposed in the UI?
-		- In each form or centrally? or both?
-		- What is most convenient?
-	- Check design docs for information about this that was planned already
-	- Where you create custom fields and edit 
-	- Set if visible / hidden
-		- Ties into main grid stuff below
 	- 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?
 		- test scenario where a custom field type is changed, how does it react, what code changes are required
@@ -288,6 +260,7 @@ TODO: Local user settings page / UI where can
 TODO: License trial handling front end code to make my life easier
 
 TODO: Add formstate data to technical support information
+	- whut?  Not sure what this is
 
 TODO: Need to do all outstanding edit form stuff next