This commit is contained in:
@@ -23,6 +23,69 @@ TODO CLIENT STUFF
|
|||||||
|
|
||||||
- Clean up todo below here and up to "Stage 2", seems to be a lot of wild speculation and repeated stuff, need a clean list of discrete actionable items.
|
- Clean up todo below here and up to "Stage 2", seems to be a lot of wild speculation and repeated stuff, need a clean list of discrete actionable items.
|
||||||
|
|
||||||
|
- Just get basic Functionality working then iterate rather than trying to plan out everything at once!!
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
- numeric inputs need to be set as such so that the number keyboard appears
|
||||||
|
|
||||||
|
- CRUD form for widget that supports all the aspects (NEED THIS BEFORE MUCH OTHER CODING HAPPENS)
|
||||||
|
|
||||||
|
|
||||||
|
- Everything needs to work in this form right down to the reports so that once it's done I can move forward confidentally with testing, demo-ing and with cranking out the other forms
|
||||||
|
- Don't want to solve any problems that should have been solved with this form later as I will inevitably be full on copy and pasting once I get it down and so it needs to be as solid as possible First
|
||||||
|
- Every type of entry field fully localized properly including numeric, date, time, tags etc
|
||||||
|
- Client: initialize after login sets locale formats for everything.
|
||||||
|
- Best to do this useroptions stuff after a form is in place that I can play with at the client and experiment to see what is possible
|
||||||
|
- How much flexibility do we have to set things like numeric / currency input / display format?
|
||||||
|
- First it gets useroptions to know what to override or not, then sets defaults based on browser or override settings in central client area for all display/parsing etc
|
||||||
|
- All numeric and date displays and input in locale format
|
||||||
|
- A printable report
|
||||||
|
- Even if there is no designer yet for the report and it has to use a manually created report format HTML doc
|
||||||
|
- Error and validation properly implemented
|
||||||
|
- broken rule display
|
||||||
|
- Error reporting overall properly implemented
|
||||||
|
- ensure error messages that come back from API that start with LT: will be localized correctly before display / logging (may need string interpolation too for some in future, consider that)
|
||||||
|
- Dirty check and warning if navigate away.
|
||||||
|
- Dirty form check and prevent route leave: https://router.vuejs.org/guide/advanced/navigation-guards.html#in-component-guards
|
||||||
|
- Menu with common options
|
||||||
|
- File attachments set and get
|
||||||
|
- Duplicate
|
||||||
|
- ETC (look it up)
|
||||||
|
- WIKI PAGE
|
||||||
|
- Doesn't require docs support as is now changed to a standard file attachment
|
||||||
|
- This should just be kept in mind as a technique to use if necessary:
|
||||||
|
- https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3494
|
||||||
|
- UI:GENERAL:LAYOUT: - All layout, not just workorder needs to be modular and optional sections with simple starting view.
|
||||||
|
|
||||||
|
|
||||||
|
- SERVER CHANGE USEROPTIONS SETTINGS NEEDED:
|
||||||
|
- Best to do this useroptions stuff after a form is in place that I can play with at the client and experiment to see what is possible
|
||||||
|
- Will need currency symbol, date format, numeric format from user settings at server
|
||||||
|
|
||||||
|
- Allow a choice: browser native display format or forced format set in useroptions
|
||||||
|
- Code the client so it will do either one from a setting fetched off the server for a session
|
||||||
|
|
||||||
|
- THESE SETTINGS NEEDED FOR USEROPTIONS
|
||||||
|
- Use browser TimeZone
|
||||||
|
- Use this timezoneoffset (already have this)
|
||||||
|
- Use browser Numeric format
|
||||||
|
- Override browser with these numeric format settings instead (see below)
|
||||||
|
- Digit grouping symbol i.e. the , in 1,000,000
|
||||||
|
- Decimal symbol i.e. the . in 1.00
|
||||||
|
- Currency symbol string (may be more than one character in some locales i.e. "Eur")
|
||||||
|
- negative display format one of these: -1.1, (1.1), 1.1-
|
||||||
|
- Use browser Datetime format
|
||||||
|
- Override browser datetime with these settings instead (see below)
|
||||||
|
- One single date format string? Or one for time, one for date and one for date/time? (see v7)
|
||||||
|
- Take from day.js (https://github.com/iamkun/dayjs/blob/master/docs/en/API-reference.md#list-of-all-available-formats)
|
||||||
|
- Do not allow anything other than numeric display, i.e. no January or Saturday so we avoid localization issues
|
||||||
|
|
||||||
|
|
||||||
|
......
|
||||||
|
|
||||||
|
|
||||||
- LIST
|
- LIST
|
||||||
- Ellipsis submenu with mass ops options and other list wide options appear there
|
- Ellipsis submenu with mass ops options and other list wide options appear there
|
||||||
- Print / report
|
- Print / report
|
||||||
@@ -30,95 +93,19 @@ TODO CLIENT STUFF
|
|||||||
- They come from the api as an array of strings
|
- They come from the api as an array of strings
|
||||||
- Check the rights to the list before it gets the data
|
- Check the rights to the list before it gets the data
|
||||||
- Sort and filter dialog
|
- Sort and filter dialog
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
- numeric inputs need to be set as such so that the number keyboard appears
|
|
||||||
|
|
||||||
- CRUD form for widget that supports all the aspects (NEED THIS BEFORE MUCH OTHER CODING HAPPENS)
|
|
||||||
- This should just be kept in mind as a technique to use if necessary:
|
|
||||||
- https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3494
|
|
||||||
- UI:GENERAL:LAYOUT: - All layout, not just workorder needs to be modular and optional sections with simple starting view.
|
|
||||||
|
|
||||||
|
|
||||||
- Everything needs to work in this form right down to the reports so that once it's done I can move forward confidentally with testing, demo-ing and with cranking out the other forms
|
|
||||||
- Don't want to solve any problems that should have been solved with this form later as I will inevitably be full on copy and pasting once I get it down and so it needs to be as solid as possible First
|
|
||||||
- Every type of entry field fully localized properly including numeric, date, time, tags etc
|
|
||||||
- A printable report
|
|
||||||
- Even if there is no designer yet for the report and it has to use a manually created report format HTML doc
|
|
||||||
- Error and validation properly implemented
|
|
||||||
- Error reporting overall properly implemented
|
|
||||||
- Dirty check and warning if navigate away.
|
|
||||||
- Menu with common options
|
|
||||||
- File attachments set and get
|
|
||||||
- Duplicate
|
|
||||||
- ETC (look it up)
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
- Make the following widgets for small screen, drag out size and see what can be done to benefit medium+ sizes, so two sizes for now
|
|
||||||
- Just get basic Functionality working then iterate rather than trying to plan out everything at once!!
|
|
||||||
- Mockup filter popup dialog or filter in place near header with expansion thing
|
|
||||||
- Edit dialog or edit in place?
|
|
||||||
|
|
||||||
- Widget list component that works with real data
|
- Widget list component that works with real data
|
||||||
- paging, sorting, filtering (columns and by tag), items per page
|
- paging, sorting, filtering (columns and by tag), items per page
|
||||||
- Single column sorting only
|
- Single column sorting only
|
||||||
- Filter by popup dialog
|
- Filter by popup dialog
|
||||||
- generic dialog that accepts a object specifying column names and types and builds a UI with the options on it
|
- generic dialog that accepts a object specifying column names and types and builds a UI with the options on it
|
||||||
- when applied it saves it as an object that is sent up to the server for each column sorted on in query string
|
- when applied it saves it as an object that is sent up to the server for each column sorted on in query string
|
||||||
- Server list needs to accept those options and sort accordingly.
|
- Server list needs to accept those options and sort accordingly.
|
||||||
- are we getting into huge territory needing more advanced utility at server for querying from client?
|
|
||||||
- Saved filter as a whole grid component? or Stored locally with client so each client app can have individual settings (i.e. phone vs desktop can have alternate settings for same user)
|
|
||||||
or both saveable as a pick item from teh main or as a whole preset grid widget? TIME TO MARKET!!!
|
|
||||||
- Each item can be edited if they have the rights or viewed etc by opening into crud component
|
- Each item can be edited if they have the rights or viewed etc by opening into crud component
|
||||||
- List should remember where the user was when they go to edit and back again
|
- List should remember where the user was when they go to edit and back again
|
||||||
- What to do if they edit? Refresh the list but keep the same page location?
|
- What to do if they edit? Refresh the list but keep the same page location?
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
- Widget crud component that works with real data
|
|
||||||
- Dirty form check and prevent route leave: https://router.vuejs.org/guide/advanced/navigation-guards.html#in-component-guards
|
|
||||||
- broken rule display
|
|
||||||
- Error messages: When get to the CRUD form, ensure error messages that come back from API that start with LT: will be localized correctly before display / logging (may need string interpolation too for some in future, consider that)
|
|
||||||
- IN CONJUNCTION WITH BELOW AFTER FORM IS MADE USING DEFAULTS OF CLIENT:
|
|
||||||
- All numeric and date displays and input in locale format
|
|
||||||
|
|
||||||
- Client: initialize after login sets locale formats for everything.
|
|
||||||
- Best to do this useroptions stuff after a form is in place that I can play with at the client and experiment to see what is possible
|
|
||||||
- How much flexibility do we have to set things like numeric / currency input / display format?
|
|
||||||
- First it gets useroptions to know what to override or not, then sets defaults based on browser or override settings in central client area for all display/parsing etc
|
|
||||||
|
|
||||||
- SERVER CHANGE: USEROPTIONS SETTINGS NEEDED:
|
|
||||||
- Best to do this useroptions stuff after a form is in place that I can play with at the client and experiment to see what is possible
|
|
||||||
- Will need currency symbol, date format, numeric format from user settings at server
|
|
||||||
|
|
||||||
- Allow a choice: browser native display format or forced format set in useroptions
|
|
||||||
- Code the client so it will do either one from a setting fetched off the server for a session
|
|
||||||
|
|
||||||
- THESE SETTINGS NEEDED FOR USEROPTIONS
|
|
||||||
- Use browser TimeZone
|
|
||||||
- Use this timezoneoffset (already have this)
|
|
||||||
- Use browser Numeric format
|
|
||||||
- Override browser with these numeric format settings instead (see below)
|
|
||||||
- Digit grouping symbol i.e. the , in 1,000,000
|
|
||||||
- Decimal symbol i.e. the . in 1.00
|
|
||||||
- Currency symbol string (may be more than one character in some locales i.e. "Eur")
|
|
||||||
- negative display format one of these: -1.1, (1.1), 1.1-
|
|
||||||
- Use browser Datetime format
|
|
||||||
- Override browser datetime with these settings instead (see below)
|
|
||||||
- One single date format string? Or one for time, one for date and one for date/time? (see v7)
|
|
||||||
- Take from day.js (https://github.com/iamkun/dayjs/blob/master/docs/en/API-reference.md#list-of-all-available-formats)
|
|
||||||
- Do not allow anything other than numeric display, i.e. no January or Saturday so we avoid localization issues
|
|
||||||
|
|
||||||
|
|
||||||
- WIKI PAGE
|
|
||||||
- Doesn't require docs support as is now changed to a standard file attachment
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
-----------------
|
-----------------
|
||||||
|
|
||||||
TODO AFTER CLIENT block ABOVE:
|
TODO AFTER CLIENT block ABOVE:
|
||||||
|
|||||||
Reference in New Issue
Block a user