admin/raven
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Browse Source
This commit is contained in:
John Cardinal
2019-01-15 22:45:40 +00:00
parent 72c2b8f4a5
commit 09609bf1bb
9 changed files with 113 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
devdocs/specs/core-customize-form-fields.txt
View File

@@ -30,6 +30,12 @@ UI FEATURE - The ability to customize forms:
if nothing has changed the server returns the unchanged code or instead returns all the data if it is changed to save bandwidth
- RAVEN custom fields start with 1 not zero like in v7
- Import v7 custom0 to RAVEN custom1
- 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
- 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
## TODO
@@ -50,7 +56,7 @@ UI FEATURE - The ability to customize forms:
- Method: IsValidForm(string formKey) bool exists or not
- Need a FormCustom controller that supports routes for:
- #DONE# Need a FormCustom controller that supports routes for:
- #DONE# Routes for customization form populating and receiving
- GET (formkey), gets a FormOptions object that provides the basis for building the form customization view
- Also required at the client is the current form customizations if any which can be gotten from the other route for day to day ops below
@@ -59,14 +65,16 @@ UI FEATURE - The ability to customize forms:
- Localization changes are NOT handled here even though it's the same client end form, that is handled at the CLIENT end after it has updated this part separately through regular localized text routes
- To ensure proper separation of concerns
- Routes for the day to day form display purposes that efficiently fetch the form customization to use on demand and caches at the client
- #DONE# Routes for the day to day form display purposes that efficiently fetch the form customization to use on demand and caches at the client
- (GET formkey, token): Given a formkey and an *optional* concurrency token, returns one of the following:
- If no concurrency token or doesn't match the current db one then:
- a list of customized fields (not the non customized ones) so the client can display the UI correctly:
- Basically whatever is in the FormCustom table record for that formkey
- If concurrency token provided and is unchanged then simply returns a code 304 (NOT MODIFIED)
- TESTS for the above!!!
- #DONE# TESTS for the above!!!
- Put custom fields into widget object or figure out how we will handle that aspect
EXISTING v7:

7
devdocs/todo.txt
View File

@@ -19,6 +19,8 @@ SERVER
- PickListFetcher: WTF? It has a reference to widgetbiz in it, isn't this a generic class??
- AySchema: License table extra fields, remove any not required (also in model and code)
- Resource localization edit all Custom field locale keys for all langauges and change to be 1 to 16 (remove 0 and add 6 more)
- So, for example ClientCustom0 becomes ClientCustom1 and make sure the display values are identical as right now there are "My Custom0" and "Custom Field 8" in the same bunch
- Copy from WidgetCustom1 to 16 if necessary or for reference
@@ -50,8 +52,11 @@ SERVER
- PASETO instead of JWT??
- https://paseto.io/
- UPDATE: Update all modules at server and re-test
- UPDATE: Update all 3rd party libs in use with server and re-test
- It's been a while, some of the modules date to last fall
- Test on OPS server
DOCS / MANUAL
- Disable google fonts for manual / docs generator: