314 lines
16 KiB
Plaintext
314 lines
16 KiB
Plaintext
# CLIENT TODO (J.F.C. - Just fucking code it already)
|
||
|
||
|
||
## 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
|
||
|
||
#### A PHONE IS PROBABLY NOT THE MOST COMMON SIZE FORM FACTOR THAT WILL BE USED. SUPPORT PHONES, YES, BUT DON'T GET HUNG UP ON IT TO THE POINT WHERE IT RUINS THE EXPERIENCE ON A FULL COMPUTER OR TABLET
|
||
|
||
TODO NEXT
|
||
|
||
IMMEDIATE ISSUES:
|
||
How and where to display form errors that are unhandled on form and not related to notification, i.e. ErrorServerUnresponsive when attempting to use a form that was already open
|
||
|
||
See server project widget validation code which will now give server errors on certain values so can proceed with work.
|
||
Current issue is where to put notifications, code is to help test,
|
||
|
||
Issues:
|
||
|
||
ISSUE: need to display multiple types of messages, best way to do that??
|
||
- DONE: Local validation errors - this works and is done
|
||
- DONE: Server errors - This works and is done
|
||
- Application errors
|
||
- Make them show with the server error box, rejig it as a generic error box
|
||
- App errors don't need to survive page reload or api call, if they are that serious then they would be notifications instead
|
||
- Notifications, stuff that you want to know is there and can go and look at but isn't urgent enough to put in the users face
|
||
- Used for notification system, non-urgent system messages, direct messages from users etc, anything that isn't immediately important
|
||
- This seems like an application wide thing so maybe a bell icon that takes to another area of the program, or opens a div at the top or bottom of the page??
|
||
|
||
|
||
ISSUE: Not sure this is the correct approach, it's needing to iterate the return error object multiple times which is a code smell
|
||
- Once to see if there are errors and another time to build up the errors
|
||
- Maybe it should be called once only as a method after the server returns the results and the gzvalidate populates a key on the data object in the form which in turn drives the error box?
|
||
FIX:
|
||
Need to test with full features, so plow ahead getting to a normal cycle of errors and then go back and fix the things that don't work later
|
||
Scenarios:
|
||
- DONE: Local form validation errors display correctly and are cleared when edited
|
||
- Server form validation errors displayed correctly
|
||
- DONE control ones under control where local form validation errors show
|
||
- DONE whole object ones at top
|
||
- DONE Server form validation errors cleared in individual inputs upon any change to them and general if it only applies to validation
|
||
- On submit:
|
||
- Doesn't happen if any local validation errors
|
||
- DONE: All server errors clear on submit
|
||
- Validation short circuits if form is loading and no data yet
|
||
- Validation short circuits if no server errors at all
|
||
|
||
DIRTY CHECKING to short circuit rule checks
|
||
|
||
inernalChange does get set to true but only on the very first actual change, later it can be false again, however this is enough for me to detect a change and remove the server rule
|
||
|
||
|
||
direct control properties when control was changed / is dirty:
|
||
=-=-=-=-
|
||
hasColor: true
|
||
hasFocused: undefined
|
||
hasInput: true
|
||
hasMouseDown: undefined
|
||
initialValue: 8212
|
||
internalChange: true
|
||
isClearing: undefined
|
||
isFocused: true
|
||
isResetting: undefined
|
||
lazySelection: undefined
|
||
lazyValue: "82121"
|
||
|
||
|
||
Same properties when control was NOT changed:
|
||
=-=-=-
|
||
hasColor: undefined
|
||
hasFocused: undefined
|
||
hasInput: true
|
||
hasMouseDown: undefined
|
||
initialValue: null
|
||
internalChange: undefined
|
||
isClearing: undefined
|
||
isFocused: undefined
|
||
isResetting: undefined
|
||
lazySelection: undefined
|
||
lazyValue: undefined
|
||
|
||
LOADING CHECKING to short circuit rule checks when form is first loading
|
||
|
||
Vuetify Inputs have a loading property, can that be used to super short circuit rule checking?
|
||
|
||
CSS??
|
||
=-=-
|
||
I need to have my own .css file that is used by the app, right now there is no styling at all anywhere but the stock one
|
||
|
||
|
||
|
||
Get broken server rule to display in vue properly
|
||
see the "bit sketchy but seems to work" bit
|
||
Ensure a form-wide server validation error displays properly
|
||
- this page has an idea along the lines of what I was thinking: https://dev-squared.com/2018/01/18/using-modelstate-validation-vue-js-net-core-2/
|
||
|
||
|
||
End to end action
|
||
- The faster I get to a fully working basic level like being able to do data entry and submit to server new or updated records, the faster I can flesh out all the rest
|
||
- Code the submit data to server route for update
|
||
- Code for new record to the server
|
||
|
||
Simulate server broken rules so can integrate into ui and rule system
|
||
|
||
|
||
- Validation
|
||
- I also need to add that it scans and or keeps a collection of broken rules that come back from the server and each component checks a rule that checks in turn for server broken rules in last api call
|
||
- My rules object needs to be coded so I can easily specify a collection of rules appropriate to a form field
|
||
- So, for example let's say I have a date input, if I commonly need one to be required and be after or before another field then I should have a single combined rule of
|
||
RequiredAndAfterTarget and this method is aggregates both the required and the After rules into a single collection returned
|
||
|
||
- Test on mobile and desktop all browsers before moving on, it must be solid with error handling (required, after before etc) and etc and then if all is well we can move on to the other field types
|
||
|
||
|
||
|
||
|
||
|
||
|
||
DON'T code the user options with the currency symbol etc until after it's all been worked out client side. Use static values instad in locale.
|
||
Locale should fetch those settings the first time it sees they are not present so that they are refreshed upon use and are not stored in localstorage
|
||
(or should they be? anyway, can work that out later)
|
||
|
||
|
||
|
||
Other fields that are locale dependent
|
||
DateTime field next
|
||
|
||
|
||
|
||
|
||
FIXES REQUIRED
|
||
|
||
- API get code is incorrectly dealing with expired bearer cert, a 401 is returned and it tries to parse the result as if it succeeded when it really should trigger a login process
|
||
- Time zone offset mismatch warning needs expansion, it should only prompt a few times (maybe or find a way to deal with this) and it should offer to change it at the server automatically
|
||
- Localize time zone mismatch warning
|
||
- Don't like popup messages, would rather see a notification icon and be part of that unless it's super critical
|
||
- Implement a toaster or some similar notification
|
||
|
||
Figure out why custom fields don't exist in widgets test data and put it there so can code it.
|
||
Put all the widget fields on the form
|
||
Check rights when navigating to the form
|
||
Fetch the record when the form opens
|
||
Localize the validations
|
||
Ensure my own validations work to match the biz rules for the widget form.
|
||
Add update and save code
|
||
Make all fields work according to specs below
|
||
|
||
|
||
Make a basic crud form with all the fields necessary, then iterate over it adding the items below.
|
||
|
||
|
||
- CRUD form for widget:
|
||
|
||
- Needs to be a main form that is opened via route and parameter so that any part of AyaNova can just navigate to that page and it can be bookmarked.
|
||
- Not suitable for a popup form
|
||
- This means the list needs to remember where it was at when navigating back to it
|
||
|
||
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
|
||
- TEST SMALL and LARGE device layout regularly, don't get too far ahead of the testing
|
||
- 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
|
||
- numeric inputs need to be set as such so that the number keyboard appears
|
||
- And all specialty inputs of course
|
||
- Custom fields implemented!
|
||
- 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)
|
||
- Validation / validation rules
|
||
- Vee validate and vuedelate both work tightly with vuetify and v-form
|
||
- Vee-validate can be localized
|
||
- https://baianat.github.io/vee-validate/guide/rules.html#after
|
||
- 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.
|
||
|
||
- Calendar form using new vuetify calendar control
|
||
|
||
- MISC
|
||
- Search area seems to take up too much space
|
||
|
||
- 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
|
||
- Ellipsis submenu with mass ops options and other list wide options appear there
|
||
- Print / report
|
||
- Show tags in main list as they were added to widget recently
|
||
- They come from the api as an array of strings
|
||
- Check the rights to the list before it gets the data
|
||
- Sort and filter dialog
|
||
- 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.
|
||
|
||
- 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?
|
||
|
||
|
||
TESTING TODO
|
||
Localized input and parsing and validation
|
||
- Going to need to handle localized numeric entry formats
|
||
- Deal with this once form is in good shape and worth testing with different locales
|
||
-----------------
|
||
|
||
TODO AFTER CLIENT block ABOVE:
|
||
ON UPDATE: have an url that opens automatically or a notification and link to one after a new version has been detected just like visual studio does in order to show what is new in this version
|
||
|
||
ABOUT form - add the user settings such as timezone offset, locale formatting patterns etc, will be useful for troubleshooting
|
||
|
||
AUTOCOMPLETE
|
||
- This article is spot on and I need to implement it like this: http://jeremymikkola.com/posts/2019_03_19_rules_for_autocomplete.html
|
||
- Check article responses and comments here for tweaks: https://news.ycombinator.com/item?id=19438826
|
||
|
||
"THORNY ISSUES" below are needed to be resolved sooner than later
|
||
|
||
|
||
|
||
|
||
- 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!!
|
||
|
||
|