This commit is contained in:
@@ -45,10 +45,29 @@ CURRENT ROADMAP
|
||||
CURRENT TODOs
|
||||
=-=-=-=-=-=-=
|
||||
|
||||
((((((((((((((( READ HELP DOCS FOR GRIDS, SEE IF ANYTHING MISSED ABOUT PURPOSE OF THEM )))))))))))))))
|
||||
|
||||
TODO: Time to consider layout of main shell as the grids stuff is starting to touch on it
|
||||
- Right now it's just a bunch of sample stuff, not realistic
|
||||
- Navigation panel can support up to 3 layers https://vuetifyjs.com/en/components/lists#nested-lists
|
||||
- So, could replicate existing v7 nav panel essentially, just not as many layers for workorders likely but who knows at this point, cross that ditch when...etc etc
|
||||
- TTM
|
||||
- This is increasingly becoming the driving force here
|
||||
- Not going with the fancy modular recomposable UI and I know v7 style will work
|
||||
- See the todo somewhere down below regarding the shell in case anything I forgot
|
||||
- Consider LOGOUT as a button at the very bottom of the nav menu using the APPEND slot as it is done in this example here: https://vuetifyjs.com/en/components/navigation-drawers#colored-drawer
|
||||
|
||||
|
||||
((((((((((((((( DETERMINE IF CAN USE MINIMAL SET OF STATIC COLUMNS by looking at v7, imagine it's v8 with only limited fields (hide the rest for a test view) and considering main objects and how they will show )))))))))))))))
|
||||
TODO: Two kinds of mass fetch records in RAVEN
|
||||
- 1) Reporting records
|
||||
- Need to filter, sort and will probably pull in many different tables so would be a set of dedicated objects for that purpose at server
|
||||
- Not using name display format as it's a reporting responsibility how the raw data is displayed at that point
|
||||
- 2) Selection records
|
||||
- USED IN
|
||||
- In forms in pick lists for selection
|
||||
- In main grids also for selection and viewing and triggering reporting (but reporting uses different lists to feed to report generator)
|
||||
- Need to filter sort and search
|
||||
- Uses templated name display format
|
||||
- Server needs to take into account display format
|
||||
|
||||
TODO: Errors - make sure all user displayed errors have an error number if they might be something tech support needs to know (case 1854)
|
||||
- I guess this is a LT feature really
|
||||
@@ -67,7 +86,7 @@ TODO: DATE FILTER add month names for month this year case 1441
|
||||
TODO: MAIN GRID LIST ANALYSIS, DESIGN AND COMPLETION KEEPING IN MIND TTM
|
||||
- WHAT is the actual purpose of the grid lists?
|
||||
- WENT THROUGH ALL CASES FOR RAVEN
|
||||
- Found nothing really that requires main grids other than the most basic reasons already here like selection, search, add report, so the grid columns are mostly for looking at them and creating filters
|
||||
- Found nothing really that requires main grids other than the most basic reasons already here like selection, search, add, report, so the grid columns in v7 are mostly for looking at them and creating filters
|
||||
- SEARCH that type of object only !!!!
|
||||
- Add new record of that type
|
||||
- Selection of record(s) FILTERED OR ALL for reporting or mass operations
|
||||
@@ -86,6 +105,12 @@ TODO: MAIN GRID LIST ANALYSIS, DESIGN AND COMPLETION KEEPING IN MIND TTM
|
||||
- Other columns that are critical would be any that are stock and required
|
||||
- Leaning toward static fixed column display that is sortable
|
||||
- Not seeing any real reason to have many columns other than for viewing purposes and filtering which can be done outside of the grid
|
||||
- IDEA: if I have a kick ass display format template builder that people can use easily then they can just decide which fields in which order to use for the "Name" field and then no need to include other columns, they can just define them for normal display
|
||||
- Going to need this as a feature anyway, was previously for picklist selection in forms, but would apply to main grids as well.
|
||||
- IDEA: right now on narrow window the name collapses into multiple rows as it tries to cram all fields into display
|
||||
- Remove / add fields depending on view port width
|
||||
- So minimum is the name and it expands outwards from there with stock required fields given priority
|
||||
- A maximum is also set that beyond which it doesn't add any more columns so there is lot's of clean whitespace around it
|
||||
|
||||
- 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
|
||||
@@ -114,6 +139,17 @@ TODO: MAIN GRID LIST ANALYSIS, DESIGN AND COMPLETION KEEPING IN MIND TTM
|
||||
- Reporting, list mass ops, go through cases look for stuff that will be required
|
||||
- FEATURES TO ADD
|
||||
- SEARCH (need to be able to search from the grid for that type of object)
|
||||
- Show the total quantity of records so it's clear the user is seeing a subset, i.e. "Showing 100 records of 30,124 (filtered)" or something to that effect.
|
||||
- For efficiency this might need to be a fuzzy number gathered periodically at the server as part of a job and put on a route?
|
||||
- Don't want to count them every time the list is fetched....or do I? Maybe it's pretty efficient in Postgres?
|
||||
- Show current filter summary or text name of filter at top of filter
|
||||
- going to need filter name and also a summarized fragment of text showing criteria for reporting so also could purpose that list to show current filter?
|
||||
- Filter picklist will show name for the current filter and sb at top of filter right up front
|
||||
-
|
||||
- Needs to remember last settings (stored centrally) like filter used, number of rows etc
|
||||
- When user opens up AyaNova it should always look the same in each area as last time they were there
|
||||
|
||||
|
||||
|
||||
TODO: Make errorBoxError message box on all forms a component instead as it's just boilerplate
|
||||
|
||||
|
||||
Reference in New Issue
Block a user