From 3f8bc27738128f8c4edafbb7de38283a851577a7 Mon Sep 17 00:00:00 2001 From: John Cardinal Date: Tue, 3 Dec 2019 00:25:34 +0000 Subject: [PATCH] --- ayanova/devdocs/todo.txt | 84 +++++++++++++++++++--------------------- 1 file changed, 40 insertions(+), 44 deletions(-) diff --git a/ayanova/devdocs/todo.txt b/ayanova/devdocs/todo.txt index e9a8a9ae..6ed32bfe 100644 --- a/ayanova/devdocs/todo.txt +++ b/ayanova/devdocs/todo.txt @@ -48,21 +48,44 @@ CURRENT TODOs TODO: MOVE THIS DOWN? AFTER ALL WIDGET FORM STUFF IS DONE Form customize UI - 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 + - I was leaning towards *not* mass changing the underlying records at the server when a type changes only because users may accidentally make a change and then want to reverse it before any records are affected. + - However this means the client needs to deal with incompatible data + - POTENTIAL FIX: Maybe the server should "vet" custom field data when it's about to send it out to the client and if it detects an invalid value it scrubs it for that record at that moment in time before it sends it off + - This way the client is always working with the correct data and also no mass changes are made at the server and if the user chooses not to save the record at the client then nothing is affected + - Maybe a function that all customfield able objects call? +TODO: Grid form analysis and completion + - Main grid time is off from edit form time by -1 hour + - Should users be able to set columns or am I really going to force it to a preset? + - I had a customer today request the Description field from unit show in the workorder service grid, it doesn't do that + - Customers probably want the option of picking what fields show and what don't + - they will also want to set the order, maybe that's not going to be supported though + - Need to think this over, do I have defined columns or is the list just for display to select the record in which case can it just be one column with user selected values showing?? + - Security and business rules may affect this as well, for some users they have rights to some of the record but not all of it, i.e. subcontractor so we do need granular field level control over what goes out from the server and at the client expectations + - Maybe list objects also return a list of fields the current user will expect to see so the list can be pre-set up with the columns at the client *then* the data fetched to populate the list + - Server should not send fields that are restricted or have them blocked out or something. + - Main list hidden fields in edit form should not show in main grid either? + - overlaps with the user selectable stuff immediately above here + - Test with widget serial field as before + - Filtering + - Sorting + - STUB out any other main grid list options + - Put in the menu options will likely need even if not coded yet. + - go through cases find the new things that need to be on the menu and stub them out. + - Stub them out so they are there even if not functional + - Maybe make all stubbed things an alt colour so can tell at a glance what is outstanding. + - Reporting, list mass ops, go through cases look for stuff that will be required - -TODO: Bug? Set widget edit form times to 4:20pm and observe that in the main grid list it shows as 320 pm!? - -TODO: Main list hide hidden fields as well??? - - If a field is hideable and hidden then it probably shouldn't display on the main list either - - Test with widget Serial field as before - - TODO: Trial route ui support in client - Add an area to support refreshing the database and generating test data + - Would be useful to see and manage OPS things related to deployment to server just to save time, can refine them later TODO (NEEDS re-test ON MOBILE for appearance and functionality): Reports - stub out @@ -86,18 +109,13 @@ TODO: SERVER STATUS - Maybe overall testing is needed with a closed server just to suss out what to do in the UI for that, we want ops people and admins in there but not other biz users if it's locked out - Maybe an alternative page when it's locked out instead of the normal view of each view saying server down for maintenance or something -TODO: Would be useful to see and manage OPS things related to deployment to server just to save time, can refine them later +TODO: Why is there an error in the console when a user is not logged in and opens client? + - It should just go to login, no error should show in the console -TODO: (may be done already) modify the inventory-widget-edit form initialization shit so that the stuff needed after form loads still happens but the before is moved to route before enter and that it's all called - with two separate methods: One standard one for init form before it is loaded and one for init form stuff for after it's loaded. BeforeLoadInit, AfterLoadInit or something - TODO: DataDump plugin needs an explanation of what it is in the flow, right now it's completely cryptic and people may be using it for stuff thinking it's for something it's not - Also, verify it's manager account only that can run it or maybe someone with total rights to everything? - - - TODO: Record history display / check other AyaNova 7 options / buttons that need to carry forward - implement and componentize - Record history could be displayed on a timeline: https://vuetifyjs.com/en/components/timelines @@ -111,20 +129,16 @@ TODO: - Time zone mismatch message sb localized and far shorter TODO: WIKI - componentize - in vue slot? or separate page, probably separate page as it will need full screen likely for most users + TODO: Attached documents - componentize + TODO: save and new button in edit form like v7? Or only from main? - will the menu be too crowded? RETEST HERE ON ALL DEVICES -TODO: 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 - - I was leaning towards *not* mass changing the underlying records at the server when a type changes only because users may accidentally make a change and then want to reverse it before any records are affected. - - However this means the client needs to deal with incompatible data - - POTENTIAL FIX: Maybe the server should "vet" custom field data when it's about to send it out to the client and if it detects an invalid value it scrubs it for that record at that moment in time before it sends it off - - This way the client is always working with the correct data and also no mass changes are made at the server and if the user chooses not to save the record at the client then nothing is affected - - Maybe a function that all customfield able objects call? + TODO: Clean up TODO list, have only actionable, not completed items. - Make a to_test.txt doc so can move todo's to to test doc for testing @@ -148,12 +162,16 @@ TODO: AUTOMATIC TEST *** SUPER IMPORTANT ***** TODO: Outstanding case with vuetify bug in clear button when readonly, check if fixed and if it isn't might need a workaround + - They decided to close the issue rather than fix it: + TODO: Document in user manual the Widget form as an example with instruction on how to use the various controls etc - "Anatomy of a AyaNova Form" TODO: Server needs to do widget validation 666.66 dollar amount test rules not only in debug mode so can test when put up to the devops server - Test code is in widgetbiz.cs around line 445, but do we need it? Maybe just find a proper server error that can be made to happen naturally? + TODO: INVESTIGATE - DO I need to institute a back button? (in APP MODE?? installed to "desktop" on device will I be able to easily navigate without back and forward buttons) + TODO: INVESTIGATE / REDO THE TOP LEVEL SHELL - TIME TO MARKET / Is my shell layout fucked? - wouldn't it just suck to have all those lists exposed at once in inventory? - Opening that page once they are all there would trigger huge traffic to the server, better to confine things to their own area as much as possible @@ -184,34 +202,12 @@ TODO: INVESTIGATE / REDO THE TOP LEVEL SHELL - TIME TO MARKET / Is my shell layo -TODO: Automated testing of UI by driving web interaction, that needs to be instituted asap - - However, until the shell is worked out it might be best to hold off, that's why I put it below the shell stuff above TODO: INVESTIGATE - Dark mode / theming (dark with a half moon icon) - If it can be done with a half hour of work and doesn't affect anything support wise or maintainance wise then yes - Also see how to allow theming maybe or colour choices? Nah, dark mode is the most useful; I should decide the colours and stick with them it's part of our image -TODO: INVESTIGATE - Grid / LIST VIEW COLUMNS SELECTABLE?? I know customers will want to control what shows in the list views (grid equivalent in v8). - - I had a customer today request the Description field from unit show in the workorder service grid, it doesn't do that - - Customers probably want the option of picking what fields show and what don't - - they will also want to set the order, maybe that's not going to be supported though - - Need to think this over, do I have defined columns or is the list just for display to select the record in which case can it just be one column with user selected values showing?? - - Security and business rules may affect this as well, for some users they have rights to some of the record but not all of it, i.e. subcontractor so we do need granular field level control over what goes out from the server and at the client expectations - - Maybe list objects also return a list of fields the current user will expect to see so the list can be pre-set up with the columns at the client *then* the data fetched to populate the list - - Server should not send fields that are restricted or have them blocked out or something. - - - - -TODO: List view FILTER button - - Get it working -TODO: Grid list STUB OUT other options - - Put in the menu options will likely need even if not coded yet. - - go through cases find the new things that need to be on the menu and stub them out. - - Stub them out so they are there even if not functional - - Maybe make all stubbed things an alt colour so can tell at a glance what is outstanding. - - Reporting, list mass ops, go through cases look for stuff that will be required #locale stuff TODO: //todo: timezone doesn't match, offer to fix it in initialize.js there needs to be a prompt and autofix