From 1b42eb86328e4544154d00276b5d10c6eaeb5b40 Mon Sep 17 00:00:00 2001 From: John Cardinal Date: Tue, 10 Dec 2019 18:41:01 +0000 Subject: [PATCH] --- ayanova/devdocs/todo.txt | 33 +++------------------------------ 1 file changed, 3 insertions(+), 30 deletions(-) diff --git a/ayanova/devdocs/todo.txt b/ayanova/devdocs/todo.txt index 1f74cd4e..d367b6f2 100644 --- a/ayanova/devdocs/todo.txt +++ b/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 - - 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 +TODO: FORM CUSTOMIZATION FORM - 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