devdocs/specs/core-customize-form-fields.txt

@@ -17,8 +17,8 @@ UI FEATURE - The ability to customize forms:
         - 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
-    - Set the localized text for the current locale for every existing field and any custom ones enabled
-    - Show in the UI that a particular field is shared so that users know they are changing system wide i.e. "CommonActive" or "Tags"
+    - 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
@@ -33,8 +33,7 @@ UI FEATURE - The ability to customize forms:
     - SERVER HANDLING
         - Custom fields are stored *with* their associated record in a single TEXT column as a serialized JSON object
             - {c1:"blah",c2:"blah",c3:"blah".....c16:"blah"}
-        - According to the docs https://www.postgresql.org/docs/9.1/datatype-character.html this is pretty efficient
-        - I don't like the idea of an outside table holding all custom values, it would be hammered pretty hard, this way the data stays with it's record
+        - According to the docs https://www.postgresql.org/docs/9.1/datatype-character.html this is pretty efficient        
         - The server doesn't validate it or anything, just stores what the client provides and retrieves what the client needs and the client co-erces the value to the correct type
         - If a user changes the underlying objects type then the client must handle discrepencies and attempt to fix it.
             - So the client end must handle adapting the value if the type changes
@@ -84,7 +83,7 @@ UI FEATURE - The ability to customize forms:
 
         - #DONE# TESTS for the above!!!
 
-    - Put custom fields into widget object or figure out how we will handle that aspect
+    - #DONEPut custom fields into widget object or figure out how we will handle that aspect
     
 
 EXISTING v7: