This commit is contained in:
@@ -47,7 +47,7 @@ CURRENT TODOs
|
||||
|
||||
SHELL / NAV / MENUS / LAYOUT
|
||||
|
||||
|
||||
TODO: Read through grid item below, cogitate then make todo's with actual planned changes that must happen to implement, then whack them off one by one ;)
|
||||
|
||||
TODO: MAIN GRID LIST ANALYSIS, DESIGN AND COMPLETION KEEPING IN MIND TTM
|
||||
- MOST RECENT NOTES: Grid looks like shit, I know it's not done yet and it's the major UI element to work on next after these details for the shell, but ... it looks like shit, consider phone first when designing it
|
||||
@@ -61,7 +61,7 @@ TODO: MAIN GRID LIST ANALYSIS, DESIGN AND COMPLETION KEEPING IN MIND TTM
|
||||
- SEARCH that type of object only !!!!
|
||||
- Add new record of that type
|
||||
- Selection of record(s) FILTERED OR ALL for reporting or mass operations
|
||||
- Feeding into reports that are highly customizable and can be used to view all data rather than fucking around with grid columns?
|
||||
- Feeding into reports that are highly customizable and can be used to view all data in any way desired by user rather than fucking around with grid columns
|
||||
- Mass operations
|
||||
- in v7 could do a mass op on *all* records, but here that would mean downloading all the records into the client which could be very fucking slow or too big
|
||||
- Reporting: in v7 could report against individually selected items or all
|
||||
@@ -70,6 +70,7 @@ TODO: MAIN GRID LIST ANALYSIS, DESIGN AND COMPLETION KEEPING IN MIND TTM
|
||||
- i.e. report on all workorders for year maybe is too large but if filter by month then can print each month separately
|
||||
- CLIENT for selective ops only, for any feature that is going to commonly be required to use against *all* records it should be a defined route at the server and the server should handle it when client triggers
|
||||
|
||||
|
||||
|
||||
- COLUMNS DISPLAYED
|
||||
- Crtical columns are the name or equivalent that is unique as the primary item
|
||||
@@ -108,17 +109,7 @@ TODO: MAIN GRID LIST ANALYSIS, DESIGN AND COMPLETION KEEPING IN MIND TTM
|
||||
- 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
|
||||
- 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
|
||||
|
||||
- Some stuff that might not be relevant from earlier (duplicated at server todo project)
|
||||
- TODO: Two kinds of mass fetch records in RAVEN
|
||||
- 1) Reporting records
|
||||
@@ -134,6 +125,33 @@ TODO: MAIN GRID LIST ANALYSIS, DESIGN AND COMPLETION KEEPING IN MIND TTM
|
||||
- ACTION required:
|
||||
- Make sure the server supports this
|
||||
|
||||
- GRID TODO FOR SURE
|
||||
- DETERMINE AND IMPLEMENT INCREASED MAXIMUM ROW COUNT ALLOWED
|
||||
- Changes required at server and client (need more options at client for selection in drop down max rows thingie)
|
||||
- Also docs for api need changing
|
||||
- In light of mass ops above what is the best practical limit to number of rows to bring down?
|
||||
- I'm thinking some people are sitting on the local network with the server and don't have an issue with a huge amount of data coming down the pipes
|
||||
- Determine a sane maximum and implement it
|
||||
- See what other commonly used api's are doing out there
|
||||
- Check on stackoverflow probably been asked recently in modern times
|
||||
|
||||
|
||||
- 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?
|
||||
- Doesn't it already count them for paging purposes and even sends that value to the client already?
|
||||
- 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
|
||||
|
||||
TODO: TIME ZONE MISMATCH MESSAGE
|
||||
|
||||
Reference in New Issue
Block a user