This commit is contained in:
163
devdocs/todo.txt
163
devdocs/todo.txt
@@ -7,155 +7,21 @@ Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOiIxNTQ0NTU5NzAwIiwiZXhwIjoi
|
|||||||
|
|
||||||
|
|
||||||
Need a sprint to get to a fully testable client with entry form, list and as much as possible all features from COMMON-* specs list
|
Need a sprint to get to a fully testable client with entry form, list and as much as possible all features from COMMON-* specs list
|
||||||
|
Do the stuff in the Client todo first then back to the server as required.
|
||||||
|
|
||||||
-----------------------
|
-----------------------
|
||||||
|
|
||||||
///
|
SERVER
|
||||||
TODO CLIENT STUFF
|
- JWT issues??
|
||||||
|
- potentially lots of issues, look into it as using them kind of mindlessly right now.
|
||||||
- LIST
|
It could be simply that people are attempting to do other things I am not but to be safe read the criticism and see if any of it applies:
|
||||||
- Overall list menu toolbar at top with following icons:
|
http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/
|
||||||
- Add new item
|
https://stackoverflow.com/questions/27301557/if-you-can-decode-jwt-how-are-they-secure/27301616#27301616
|
||||||
- Filter list
|
https://news.ycombinator.com/item?id=14292223
|
||||||
- Refresh
|
https://news.ycombinator.com/item?id=18804875
|
||||||
- Ellipsis submenu with mass ops options and other list wide options appear there
|
|
||||||
- Print / report
|
|
||||||
- How to show tags?
|
|
||||||
- In main list?
|
|
||||||
- Only in detail?
|
|
||||||
- Check the rights to the list before it gets the data
|
|
||||||
- Edit / Trash buttons in grid are too small on a phone with fat fingers
|
|
||||||
- TWO api calls are made when list is opened, sb one only.
|
|
||||||
- Should list or any widgets fetch data automatically on display or should they have some way of requesting it to save bandwidth? (TTM CADILLAC PROBLEM?)
|
|
||||||
- Should the list be narrow to start and expand on demand?(TTM CADILLAC PROBLEM?)
|
|
||||||
- Login needs to scroll higher or logo smaller on sm so that the keyboard doesn't obscure the login lines
|
|
||||||
- Need a test user that has access to every possible role so that I can see all the roles for testing purposes
|
|
||||||
- About page has too big of margins on each side of display
|
|
||||||
- View log page has log in a small window with scroll bars instead of full screen
|
|
||||||
- numeric inputs need to be set as such so that the number keyboard appears
|
|
||||||
- Make the copyright banner at bottom left aligned, right now it seems weird in small iPhone size when it breaks to two lines (make text smaller?)
|
|
||||||
- Change server api page favicon to look like a SERVER version of the AyaNova logo, not the same one as the client uses [ fuck it, why? TTM!]
|
|
||||||
- Disable google fonts for manual / docs generator:
|
|
||||||
- first need to upgrade to latest mkdocs AND material theme for mkdocs
|
|
||||||
- https://www.mkdocs.org/#installation
|
|
||||||
- https://github.com/squidfunk/mkdocs-material
|
|
||||||
- https://squidfunk.github.io/mkdocs-material/compliance/
|
|
||||||
- Once docs no longer need google fonts can adjust the devops nginx config and remove the overrides for CORS and all that shit.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
- 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
|
|
||||||
- paging, sorting, filtering (columns and by tag), items per page
|
|
||||||
- Single column sorting only
|
|
||||||
- Filter by popup dialog
|
|
||||||
- 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
|
|
||||||
- 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
|
|
||||||
- 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?
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
- 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
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
-----------------
|
|
||||||
|
|
||||||
TODO AFTER CLIENT block ABOVE:
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
- Stage 2 AFTER POSTED TEST ROUND COMPLETED
|
|
||||||
- Error handling at client (log? display?)
|
|
||||||
- Notification of some kind (bell / toast)
|
|
||||||
- Add intro.js somewhere, even if just a quick hello type thing with one single pointer to something on the screen
|
|
||||||
- Look into: should each component do it's own ajax calls?
|
|
||||||
- Make a widget component / form to view/list/enter/edit
|
|
||||||
- Graph / Readonly UI component
|
|
||||||
- Widget: List, search, edit, localized WIDGET UI components
|
|
||||||
- Post up another build with the entry form and re-round of testing
|
|
||||||
|
|
||||||
- Stage 2.5 TESTING
|
|
||||||
- Enable some end to end testing and use it going forward all over.
|
|
||||||
|
|
||||||
- Stage 3:
|
|
||||||
- At the end of this phase re-assess and see what needs to be the focus going forward and if anything is amiss
|
|
||||||
- Plan out the next phase
|
|
||||||
- UI layout design, how I want to see things, don't re-invent the wheel; v7 isn't perfect but I don't have forever either
|
|
||||||
- Just remember roles and role based security and that might lead into the UI
|
|
||||||
- the dashboard can drive a lot because for example a graph or list of workorders could also be where you add a new wo
|
|
||||||
- Thorny issues:
|
|
||||||
- Reporting
|
|
||||||
- Notifications from the server
|
|
||||||
- File upload / download
|
|
||||||
- Offline abilities?
|
|
||||||
- TIME TO MARKET TIME TO MARKET TIME TO MARKET
|
|
||||||
- RELEASE IT, RELEASE IT, RELEASE IT!!!!
|
|
||||||
- Need a good think about this, time to market is of utmost importance but it would not hurt to see what can be done now or defferred to vNext
|
|
||||||
- v7 is technically an always online app so there's that.
|
|
||||||
- Would be nice to maybe be able to do some limited stuff offline
|
|
||||||
- scope out a scenario or leave for vNext?
|
|
||||||
- Fill out a workorder that is already up on the phone?
|
|
||||||
- Parts can't be cached locally, there could be thousands, but maybe labour only is supported?
|
|
||||||
- Maybe parts can be entered as text when offline for later lookup?
|
|
||||||
- NOTE: many users want to see some progress on v8 so it's important that the initial shell have some "flash" to it
|
|
||||||
- Nice transitions
|
|
||||||
- Some sample charts
|
|
||||||
- test well on all form factors
|
|
||||||
- Have examples of a form with all RAVEN required control types enabled
|
|
||||||
- Use Intro.js to introduce the demo to new users and also to introduce the UI elements and it will be used all over the place!!
|
|
||||||
|
|
||||||
|
|
||||||
- Stage 4:
|
|
||||||
- Customer demo!!
|
|
||||||
|
|
||||||
|
- PASETO instead of JWT??
|
||||||
|
- https://paseto.io/
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
@@ -179,6 +45,13 @@ DEVOPS
|
|||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
=-=-=-
|
=-=-=-
|
||||||
some shit I probably don't need anymore:
|
some shit I probably don't need anymore:
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user