This commit is contained in:
2019-01-07 17:25:59 +00:00
parent 35b9674af1
commit 15c8c16e5f
2 changed files with 160 additions and 1 deletions

159
ayanova/devdocs/todo.txt Normal file
View File

@@ -0,0 +1,159 @@
# TODO (J.F.C. - Just fucking code it already)
Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOiIxNTQ0NTU5NzAwIiwiZXhwIjoiMTU0NzE1MTcwMCIsImlzcyI6ImF5YW5vdmEuY29tIiwiaWQiOiIxIiwiYXlhbm92YS9yb2xlcyI6IjMyNzY3In0.fMq_8Dvia63rzN_U2zjczPvUNM40OEAeI4VOeV6ulGw
## IMMEDIATE ITEMS
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
-----------------------
///
TODO CLIENT STUFF
- LIST
- Overall list menu toolbar at top with following icons:
- Add new item
- Filter list
- Refresh
- 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!!

View File

@@ -5,7 +5,7 @@
<meta http-equiv="X-UA-Compatible" content="IE=edge" /> <meta http-equiv="X-UA-Compatible" content="IE=edge" />
<meta name="viewport" content="width=device-width,initial-scale=1.0" /> <meta name="viewport" content="width=device-width,initial-scale=1.0" />
<link rel="icon" href="<%= BASE_URL %>favicon.ico" /> <link rel="icon" href="<%= BASE_URL %>favicon.ico" />
<title>ayanova</title> <title>AyaNova</title>
<!-- <link <!-- <link
rel="stylesheet" rel="stylesheet"
href="https://fonts.googleapis.com/css?family=Roboto:100,300,400,500,700,900" href="https://fonts.googleapis.com/css?family=Roboto:100,300,400,500,700,900"