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:

devdocs/specs/core-localization.txt

@@ -2,7 +2,13 @@
 
 
 REQUIREMENTS
-    - Client does *ALL* localization locally, only exception is the server ops logs
+    - CENTRAL LOCALE EDIT FORM
+    - End user customizes localizations from a central location with a kick ass search and change ability
+    - We will *not* support localization changes form by form as in v7 but only from central location
+        - Faster to code TTM
+        - User doesn't think they are only changing it on one form only
+        - Some forms don't have all the related keys on them (i.e. a list will show "Widgets" even though the edit form never shows that string)
+    - Client handles *ALL* localization presentation locally, only exception is the server ops logs
         - This saves bandwidth and hassle and leaves presentation to the client where it belongs (was a source of trouble in v7)        
     - Keys are text, human readable and as short as possible
     - Not numeric ID's for these, strictly textual
@@ -70,9 +76,6 @@ Note: still some dupes but...fuck it
    
 
 
-- TODO: As I code, I will select lt keys as required enter them below
-
-
 
 - TODO: Some of the keys are new and not translated from English, when all is done and the keys that will be carried forward are determined, check for untranslated ones
     - Use Google translate to get a rough approximation.
@@ -95,11 +98,5 @@ CHANGES:
     - If the text is changed at the server then a notification should occur for clients using that local to invalidate their cache
         - Although, that would be a pretty rare event so...maybe not so much, a logout could clear the cache or a login I guess
 
-***********************************************************************************************************************************
-
-LOCALIZED TEXT KEYS ACTUALLY USED
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-This is actually irrelevant now because I'm coding the client to only fetch the exact keys it needs for each form,
-so there could be thousands of unused keys and it wouldn't matter.