This commit is contained in:
@@ -42,71 +42,86 @@ CURRENT ROADMAP
|
||||
CURRENT TODOs
|
||||
=-=-=-=-=-=-=
|
||||
|
||||
TODO: No way to make a new widget now!!!
|
||||
TODO: save (post) of new record at client triggers renavigation to that page again which also triggers fetch
|
||||
- So what's the point of returning the full record on post?
|
||||
- Might as well return nothing if the save was successful other than the new ID
|
||||
- On the other hand, is the data still kept in the view or is create called again fresh and all that??
|
||||
TODO: Switch control has issues in mobile view throws error "touch is undefined"
|
||||
@@@@@@@@@@@ ROADMAP STAGE 1 and 2:
|
||||
|
||||
todo: save (post) of new record at client triggers renavigation to that page again which also triggers fetch
|
||||
- original:
|
||||
- So what's the point of returning the full record on post?
|
||||
- Might as well return nothing if the save was successful other than the new ID
|
||||
- On the other hand, is the data still kept in the view or is create called again fresh and all that??
|
||||
- Actually, it really doesn't navigate if it can help it to refresh vue components
|
||||
- So, is it fetching a whole fresh record after save or using the results of save returned?
|
||||
todo: add refresh button above grid, reason being that we really don't want people refreshing the ENTIRE app with a full page refresh
|
||||
- Even though we support it, it's slow and could be an issue when running in application mode with no browser controls
|
||||
|
||||
todo: back and forward buttons when running without browser controls in application mode?
|
||||
|
||||
todo: Switch control has issues in mobile view throws error "touch is undefined"
|
||||
- Update and see if fixes or else switch to some other component
|
||||
todo: clean browser open widget list doesn't fetch anything, seems to sit endlessly, only fix is to select a filter, unselect and force full refresh multiple times
|
||||
- No error at server
|
||||
- Maybe there is an issue with OLD stored list settings because completely wiping them fixes it.
|
||||
- HMMM...maybe we need to wipe the stored settings when the version changes or something, maybe this will be more of an issue later in dev process
|
||||
TODO: HELP link on listVieweditor not working
|
||||
TODO: Add test for *NULL* and not *NULL* in datalistfilter tests as there currently aren't any
|
||||
TODO: ay-data-list-view initform code shows proper way to initialize and await each step
|
||||
todo: HELP link on listVieweditor not working
|
||||
todo: Add test for *NULL* and not *NULL* in datalistfilter tests as there currently aren't any
|
||||
todo: ay-data-list-view initform code shows proper way to initialize and await each step
|
||||
- Take that model and look at all the other forms and ensure they work the same way
|
||||
TODO: Tag picker a bit buggy, when you type to search it retains the typed text in the entry box after selecting, it shouldn't
|
||||
- possibly when type then make selection the typed part sb cleared after selection
|
||||
TODO: Custom fields test it out with grid, will likely need some field type code etc or is that already in the columns, not sure
|
||||
TODO: Tags in grid display, currently shows as an array of raw text with quotes, could be better displayed
|
||||
|
||||
TODO: Select in grid fuckery when changing formats or switching between Listviews seems to trigger selection for some reason
|
||||
todo: Tag picker a bit buggy, when you type to search it retains the typed text in the entry box after selecting, it shouldn't
|
||||
- possibly when type then make selection the typed part sb cleared after selection
|
||||
|
||||
|
||||
todo: Select in grid fuckery when changing formats or switching between Listviews seems to trigger selection for some reason
|
||||
- MAKE LT() method in forms available to all vm users so don't have to keep defining it in every single form
|
||||
|
||||
|
||||
- Make functional user settings form with all overrides so can test shit out
|
||||
- Need a browser check on opening the login page that will check to ensure the browser can do the date conversions properly etc and tell user browser is unsuitable if it isn't
|
||||
TODO: Created hook is probably where I should be doing the stuff I'm doing in beforeCreate hook, test if can simply move it in widget edit form to created
|
||||
todo: Created hook is probably where I should be doing the stuff I'm doing in beforeCreate hook, test if can simply move it in widget edit form to created
|
||||
- Reason being that the data object is not fully set up in beforecreate but I'm putting data into it as if it is which seems weird
|
||||
TODO: CUSTOMIZE not working on widget edit form
|
||||
TODO: CUSTOM DATE FIELD NOT SETTING NOW??
|
||||
- todo: perhaps beforeCreate is being used wrongly in widget edit form, need to take a re-look to ensure it's correct before I copy it endlessly
|
||||
|
||||
todo: CUSTOMIZE not working on widget edit form
|
||||
|
||||
todo: CUSTOM DATE FIELD NOT SETTING NOW??
|
||||
- Retest every kind of custom field
|
||||
|
||||
TODO: toolbar above grid for filters, refresh etc (make it a standard component?)
|
||||
todo: toolbar above grid for filters, refresh etc (make it a standard component?)
|
||||
|
||||
TODO: SEARCH UI
|
||||
todo: SEARCH UI
|
||||
|
||||
|
||||
|
||||
TODO: Make sure scroll position is respected and saved when editing a widget and coming back to the list
|
||||
todo: Make sure scroll position is respected and saved when editing a widget and coming back to the list
|
||||
|
||||
|
||||
PICKLISTS:
|
||||
|
||||
TODO: CLIENT PICKLIST DATALISTVIEW selector form
|
||||
AUTOCOMPLETE
|
||||
- This article is spot on and I need to implement it like this: http://jeremymikkola.com/posts/2019_03_19_rules_for_autocomplete.html
|
||||
- Check article responses and comments here for tweaks: https://news.ycombinator.com/item?id=19438826
|
||||
todo: CLIENT PICKLIST DATALISTVIEW selector form
|
||||
- Will need under useroptions a central location to choose all datalistview for every type of picklist in AyaNova
|
||||
- User can leave at default or select a saved DataListView (or make one there) to use
|
||||
- Client will then pick up that format in any form where it's required
|
||||
|
||||
TODO: MAKE PICKLIST COMPONENT Select lists and filtering by tag "select-search-filter-control"
|
||||
todo: MAKE PICKLIST COMPONENT Select lists and filtering by tag "select-search-filter-control"
|
||||
- Implement it as a component with built in searching and tag selection that is sticky by individual form item
|
||||
- this is an important crucial item and needs to be easy and clean
|
||||
- I'm thinking it auto searches by entry like RI, but you can open more UI and select tags to filter with it
|
||||
- Or maybe it's part of datafilter too?
|
||||
- See add food filter in diary in chronometer app for inspiration (though theirs is a bit dumb, you can only select one tag)
|
||||
TODO: Utilize new picklist in Widget form to select something that exists and can then test out DataListView etc
|
||||
todo: Utilize new picklist in Widget form to select something that exists and can then test out DataListView etc
|
||||
|
||||
|
||||
|
||||
|
||||
TODO: Client API code handle ?? (NO IDEA, maybe meaning update client after all changes at server?)
|
||||
todo: Client API code handle ?? (NO IDEA, maybe meaning update client after all changes at server?)
|
||||
|
||||
|
||||
TODO: Make errorBoxError message box on all forms a component instead as it's just boilerplate
|
||||
todo: Make errorBoxError message box on all forms a component instead as it's just boilerplate
|
||||
|
||||
TODO: TIME ZONE MISMATCH MESSAGE
|
||||
todo: TIME ZONE MISMATCH MESSAGE
|
||||
- This is actually quite important for relative date filtering lists
|
||||
- Make it automatically set the time zone offset by a actionable click on the time zone mismatch message
|
||||
- This way user knows it's happened and does it on purpose when appropriate
|
||||
@@ -114,38 +129,38 @@ TODO: TIME ZONE MISMATCH MESSAGE
|
||||
- It may need a logout and back in unless it can just set the local setting which I guess it can, be aware of that anyway
|
||||
- Time zone mismatch message sb localized and far shorter
|
||||
|
||||
TODO: Workorder/quote/pm templates
|
||||
todo: Workorder/quote/pm templates (MENU ITEM)
|
||||
- Put the link to access them into their own type, i.e. Workorder templates are accessed from either the grid listing workorders or inside an individual or perhaps BEST IDEA in the NEW menu where you pick a template !!!!!
|
||||
|
||||
TODO: Hover / hint text on copy log and log buttons (and possibly others?)
|
||||
todo: Hover / hint text on copy log and log buttons (and possibly others?)
|
||||
|
||||
TODO: Modify underconstruction to support alternate size image
|
||||
todo: Modify underconstruction to support alternate size image
|
||||
- right now it just cuts off on smaller form factors, would be much nicer and cleaner if it shows responsively
|
||||
- Important because it's going to be seen by beta testers
|
||||
- https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images
|
||||
- https://vuetifyjs.com/en/components/images
|
||||
|
||||
TODO: SERVER STATUS
|
||||
todo: SERVER STATUS
|
||||
- check server status on attempt to login for first time or whatever, it should give a prominent warning if the server is unavailable due to closed for maint or whatever rather than just timing out.
|
||||
- Also it allows login which is good but it should restrict the UI if it's a fresh login to a closed server rather than just failing to do certain things
|
||||
- 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: Why is there an error in the console when a user is not logged in and opens client?
|
||||
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: ANY TIME - SIDE v7 STUFF 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
|
||||
todo: ANY TIME - SIDE v7 STUFF 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?
|
||||
|
||||
|
||||
=================== FINALIZATION OF EDIT FORM BEFORE "STAMPING" OUT MORE ===========================================
|
||||
TODO: VET translations
|
||||
todo: VET translations
|
||||
- There are still a large number of non translated lt's in the non english stock languages (i.e. "More...")
|
||||
- Make it easy to dump the local storage locale text for vetting the translations
|
||||
- Login as each language, exercise the entire UI and then dump all the locale text that was fetched from the server and look for non english words
|
||||
|
||||
|
||||
TODO: REPORT LIST
|
||||
todo: REPORT LIST
|
||||
- Stub out some fake reports in a drop down selection for testing, doesn't have to do anything but be present
|
||||
- Test on mobile once done
|
||||
- WAS implementing as a dialog, that needs to be replaced now, either I need to follow the vuetify dialog example and put it in the shell app.vue or I'm going to use the dialog library I already have once I get an answer on templates
|
||||
@@ -157,47 +172,72 @@ TODO: REPORT LIST
|
||||
- If take generic Report option then it opens to another form for choosing the report and whether to print or not etc
|
||||
- SB localized in form as "Report" not "Print" because it's going to be likely that people will want to work with pdf (email, download) instead or just the view of it, print is maybe not a common option.
|
||||
|
||||
TODO: WIDGET EDIT FORM SAVE AND NEW BUTTON LIKE V7?
|
||||
todo: WIDGET EDIT FORM SAVE AND NEW BUTTON LIKE V7?
|
||||
- NO, just keeping this until I get here in case I think I need it again, don't need it.
|
||||
|
||||
TODO: RECORD HISTORY
|
||||
todo: RECORD HISTORY
|
||||
- implement in stubbed out separate page
|
||||
- Record history could be displayed on a timeline: https://vuetifyjs.com/en/components/timelines
|
||||
- Defaults to showing most recent stuff first in order to satisfy most common requirement of who last edited
|
||||
- Probably going to need a server route but let the UI drive it (timeline view requirements maybe?)
|
||||
|
||||
TODO: ADDITIONAL EDIT FORM BUTTONS FUNCTIONALITY STUBBED OUT OR MADE INTO TODO'S
|
||||
todo: ADDITIONAL EDIT FORM BUTTONS FUNCTIONALITY STUBBED OUT OR MADE INTO TODO'S
|
||||
- Check what is in v7 that I missed on edit forms, make TODOs for them here
|
||||
- Check what is in RAVEN STAGE 1 cases on RockFish and make TODOs for them here
|
||||
- implement and componentize
|
||||
|
||||
TODO: WIKI
|
||||
todo: WIKI
|
||||
- Implement in stubbed out existing separate page
|
||||
|
||||
TODO: ATTACHMENTS
|
||||
todo: ATTACHMENTS
|
||||
- Implement in existing stubbed out separate page
|
||||
|
||||
|
||||
|
||||
RETEST HERE ON ALL DEVICES
|
||||
|
||||
TODO: AUTOMATIC TEST *** SUPER IMPORTANT *****
|
||||
todo: AUTOMATIC TEST *** SUPER IMPORTANT *****
|
||||
- Once widget form is solid then need an automatic UI test for it to get that ball rolling and to ensure no slips during development
|
||||
- Ideally it will test every input component and validate the entire record round trips properly, maybe it needs to also try different states like creating new, editing etc
|
||||
- Also function as a "smoke" test that will heavily exercise the server and client repeatedly for as long as I let it run which will reveal issues before releases
|
||||
|
||||
TODO: Locale page with locale settings
|
||||
todo: Locale page with locale settings
|
||||
|
||||
TODO: Trial route ui support in client (ON HOLD NEEDS BACKEND WORK)
|
||||
todo: Trial route ui support in client (ON HOLD NEEDS BACKEND WORK)
|
||||
- Went to do this but found it's a bit of a maze and has some hacked temp code in the license fetch route etc for development purposes
|
||||
- Need to determine what the actual solution is for production and make some changes at the backend first
|
||||
- Also this might be the point to start looking at RockFish changes as well
|
||||
- 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: NOW THAT FORM IS THERE MOSTLY, CLEAN UP CODE FOR RE-USE in many other forms
|
||||
- Look for things to componentize
|
||||
- Can I componentize the whole form itself so that I have all the basic requirements built in and can just customize certain things for each object type?
|
||||
- Look for things that are not specific to the widget edit form but can be abstracted away for other forms
|
||||
- Don't need to replicate common code so put it somewhere else
|
||||
- Are any of the controls better as a component and self contained to save the size of the form code and complexity?
|
||||
- What I mean is, for example, a text entry field could be standardized then re-used as a component if it's props and settings take up so much space etc
|
||||
- formstate shit is also menu shit really so can they be combined somehow, like present two sets of menu options one read only and one fully read-write?
|
||||
- some forms will have special needs but could handle them outside of the regular boilerplate shit?
|
||||
|
||||
TODO: INVESTIGATE / REDO THE TOP LEVEL SHELL - TIME TO MARKET / Is my shell layout fucked?
|
||||
|
||||
|
||||
|
||||
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?
|
||||
|
||||
|
||||
=========================================================================================================
|
||||
@@@@@@@@@@@@@@@ ROADMAP STAGE 3
|
||||
|
||||
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
|
||||
- TTM: isn't it faster to just turn the menu into a tree like v7 or put options in each one's screen? (Like inventory page just shows a bunch of other icons to open details like widgets)
|
||||
@@ -226,7 +266,7 @@ TODO: INVESTIGATE / REDO THE TOP LEVEL SHELL - TIME TO MARKET / Is my shell layo
|
||||
no business software can simply hide everything and it doesn't have to suck or be ugly
|
||||
|
||||
|
||||
TODO: Clean up TODO list, have only actionable, not completed items.
|
||||
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
|
||||
- anything in this doc that isn't related directly to individual todo's other than a small big picture stuff at top sb elsewhere
|
||||
- Idea is to have a focused, clean actionable list here.
|
||||
@@ -240,69 +280,53 @@ TODO: Clean up TODO list, have only actionable, not completed items.
|
||||
- import datadump etc
|
||||
- There is a lot of crap at the bottom of this document in this todo!
|
||||
|
||||
TODO: NOW THAT FORM IS THERE MOSTLY, CLEAN UP CODE FOR RE-USE in many other forms
|
||||
- Look for things to componentize
|
||||
- Can I componentize the whole form itself so that I have all the basic requirements built in and can just customize certain things for each object type?
|
||||
- Look for things that are not specific to the widget edit form but can be abstracted away for other forms
|
||||
- Don't need to replicate common code so put it somewhere else
|
||||
- Are any of the controls better as a component and self contained to save the size of the form code and complexity?
|
||||
- What I mean is, for example, a text entry field could be standardized then re-used as a component if it's props and settings take up so much space etc
|
||||
- formstate shit is also menu shit really so can they be combined somehow, like present two sets of menu options one read only and one fully read-write?
|
||||
- some forms will have special needs but could handle them outside of the regular boilerplate shit?
|
||||
|
||||
|
||||
|
||||
|
||||
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 - 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 - Dark mode / theming (dark with a half moon icon)
|
||||
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
|
||||
|
||||
|
||||
#locale stuff
|
||||
|
||||
TODO: LOCALIZATION form
|
||||
todo: LOCALIZATION form
|
||||
- Dedicated area for localization adjustments
|
||||
- Going to be a central form for all localization not form by form
|
||||
- Review the spec doc and the cases regarding this as there are some little touches that were requested and make sense related to search and replace and other things.
|
||||
|
||||
|
||||
TODO: //todo: timezone doesn't match, offer to fix it in initialize.js there needs to be a prompt and autofix
|
||||
TODO: code the user options with the currency symbol etc on the server and then update client to fetch them. Use static values instad in locale.
|
||||
todo: //todo: timezone doesn't match, offer to fix it in initialize.js there needs to be a prompt and autofix
|
||||
todo: code the user options with the currency symbol etc on the server and then update client to fetch them. Use static values instad in locale.
|
||||
Locale should fetch those settings the first time it sees they are not present so that they are refreshed upon use and are not stored in localstorage
|
||||
(or should they be? anyway, can work that out later)
|
||||
TODO: Local user settings page / UI where can
|
||||
todo: Local user settings page / UI where can
|
||||
- set locale choices and values
|
||||
- Reset to default form settings
|
||||
- Other shit I can't think of right now but there will be a lot
|
||||
|
||||
TODO: License trial handling front end code to make my life easier
|
||||
todo: License trial handling front end code to make my life easier
|
||||
|
||||
TODO: Add formstate data to technical support information
|
||||
todo: Add formstate data to technical support information
|
||||
- whut? Not sure what this is
|
||||
|
||||
TODO: Need to do all outstanding edit form stuff next
|
||||
|
||||
todo: Need to do all outstanding edit form stuff next
|
||||
### RETEST ALL DEVICES WHEN GET TO HERE #####
|
||||
TO TEST:
|
||||
- above changes block
|
||||
|
||||
TODO: TRIAL AND LICENSE KEY / ROCKFISH STUFF
|
||||
|
||||
@@@@@@@@@@@@@@@ ROADMAP STAGE 4 - REPORTING
|
||||
Do reporting here
|
||||
Componentize of course
|
||||
|
||||
|
||||
@@@@@@@@@@@@@ ROADMAP STAGE 5
|
||||
todo: TRIAL AND LICENSE KEY / ROCKFISH STUFF
|
||||
- PLAN IN core-license-key-system.txt on server side
|
||||
- random notes maybe relevant
|
||||
- Test when logging in and server is ops only due to license not installed
|
||||
@@ -317,7 +341,7 @@ TODO: TRIAL AND LICENSE KEY / ROCKFISH STUFF
|
||||
- Client checks if server is licensed, if it isn't then it goes to a license request form in client
|
||||
- User fills out form and submits.
|
||||
|
||||
TODO: GUIDED TOUR
|
||||
todo: GUIDED TOUR
|
||||
- This is an important feature and at least get a basic one in there for starters and initial release
|
||||
- This is a replacement for the tutorials and videos in v7 a
|
||||
- Need to add that auto-pilot thingy or whatever the fuck it is that allows for guided tours in HTML apps
|
||||
@@ -465,9 +489,7 @@ ON UPDATE: have an url that opens automatically or a notification and link to on
|
||||
|
||||
ABOUT form - add the user settings such as timezone offset, locale formatting patterns etc, will be useful for troubleshooting
|
||||
|
||||
AUTOCOMPLETE
|
||||
- This article is spot on and I need to implement it like this: http://jeremymikkola.com/posts/2019_03_19_rules_for_autocomplete.html
|
||||
- Check article responses and comments here for tweaks: https://news.ycombinator.com/item?id=19438826
|
||||
|
||||
|
||||
"THORNY ISSUES" below are needed to be resolved sooner than later
|
||||
|
||||
@@ -530,10 +552,10 @@ AUTOCOMPLETE
|
||||
|
||||
This is stuff I thought of but is dubiously necessary for the initial release at least or could be polish added later:
|
||||
|
||||
TODO: Form dirty indicator on the form and easy to see, maybe the background tinges or something
|
||||
todo: Form dirty indicator on the form and easy to see, maybe the background tinges or something
|
||||
- Save button kind of is, do we need this?
|
||||
|
||||
TODO: Trial mode client should offer alternative logins right on login page and fill in for user to try out
|
||||
todo: Trial mode client should offer alternative logins right on login page and fill in for user to try out
|
||||
- So a list of user names and a short text of what that user is used for when testing
|
||||
- User can select and it will prefill in the form
|
||||
- Obvs when not trial mode then the client doesn't offer it
|
||||
Reference in New Issue
Block a user