269 lines
15 KiB
Plaintext
269 lines
15 KiB
Plaintext
# CLIENT TODO (J.F.C. - Just fucking code it already)
|
|
|
|
NEXT UP: Build, deploy and test all this block with all devices / browsers, see the test protocol.txt file for how to
|
|
|
|
TODO:
|
|
- Delete works but triggers navigation guard when it attempts to navigate away after deletion automatically
|
|
|
|
|
|
|
|
### RETEST ALL DEVICES WHEN GET TO HERE #####
|
|
|
|
|
|
End to end action
|
|
|
|
TODO UNDER CONSTRUCTION
|
|
- show under construction page in every item that has no current view so it's clear it's not just buggy and blank but purposefully so
|
|
TODO: Form dirty indicator on the form and easy to see, maybe the background tinges or something
|
|
TODO: RIGHTS FOR LIST
|
|
- TODO LIST OBJECT RESEARCH / DECISION
|
|
- TODO: ?? DECISION server widget lists and other lists
|
|
- Either the list should show items with alternate icons to EDIT if they are read only or...
|
|
- Use a generic OPEN icon and link instead and user doesn't see status until they open it.
|
|
- ReadFULL record but no change should show record read only
|
|
- To test use accounts: ReadFullRecord = AuthorizationRoles.BizAdminLimited | AuthorizationRoles.InventoryLimited
|
|
- WidgetList should check if even possible to read any part of record, if not then no link to edit
|
|
- WidgetList should check if Own record possible and check the list object for owner ID (maybe all lists will need to provide owner ID's?)
|
|
TODO: Persist view on return
|
|
- useful info here: https://vuejsdevelopers.com/2017/04/16/vue-js-browser-button-ux/
|
|
- there's another item like this below somewhere.
|
|
- Widget list, refresh page causes items per page to reset back to 5 from custom setting, it should cache that shit at least for a session anyway
|
|
- Although people probably would want this to be saved to survive sessions
|
|
- maybe it should save it per device locally only so that the customizations are local to the device so they can customize differently for different ui's?
|
|
- Or, maybe they always want to see 50 widgets no matter where but 10 clients??
|
|
|
|
|
|
TODO: NEW WIDGET
|
|
- Code for new record to the server
|
|
- Need a path to making a new record
|
|
- ID 0 maybe
|
|
TODO: Fill selection boxes, autocomplete etc
|
|
TODO: NOW THAT FORM IS THERE MOSTLY, CLEAN UP CODE FOR RE-USE in many other forms
|
|
- Don't need to replicate common code so put it somewhere else
|
|
- formstate shit is also menu shit really so can they be combined somehow, like present two sets of menu options one read only and one fully read-write?
|
|
- some forms will have special needs but could handle them outside of the regular boilerplate shit?
|
|
TODO: No 404? Can enter a route of /bad and it will just show an empty form like it thinks it's valid or something
|
|
TODO: Add toast popup or however it's supposed to happen to the gzmenu handler where popups are processed
|
|
TODO: INVESTIGATE - DO I need to institute a back button? (in APP MODE?? installed to "desktop" on device will I be able to easily navigate without back and forward buttons)
|
|
TODO: Delete widget button and rights stuff
|
|
TODO: History button, other AyaNova 7 example buttons all need to be there or their equivalent, do we need a top menu type thing?
|
|
- Also Save button at bottom seems like an issue too
|
|
|
|
TODO: About AyaNova form should show the exact client browser and device info as much as possible as it also serves as the tech support info thing
|
|
- Maybe make a support info local class in client that can gather the correct info and then can be used to both display and to send to us for support with a click
|
|
- Also add a tech support reporting form / button that will gather up support info and possibly also send it to us??
|
|
- Sends to rockfish?
|
|
- Generates an email?
|
|
- At least copy it to clipboard on desktop or enable sharing so can share on device to email
|
|
TODO: TAGS!!! Do tags mofo
|
|
TODO: //todo: timezone doesn't match, offer to fix it in initialize.js there needs to be a prompt and autofix
|
|
TODO: Automated testing of UI by driving web interaction, that needs to be instituted asap
|
|
TODO: Server needs to do widget validation 666 test rules not only in debug mode so can test when put up to the devops server
|
|
TODO: Dark mode (dark with a half moon icon)
|
|
TODO: Grid / LIST VIEW = I know customers will want to control what shows in the list views (grid equivalent in v8).
|
|
- I had a customer today request the Description field from unit show in the workorder service grid, it doesn't do that
|
|
- Customers probably want the option of picking what fields show and what don't
|
|
- Need to think this over, do I have defined columns or is the list just for display to select the record in which case can it just be one column with user selected values showing??
|
|
|
|
TODO: Outstanding case with vuetify bug in clear button when readonly, check if fixed and if it isn't might need a workaround
|
|
|
|
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
|
|
- decimalValid 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?
|
|
|
|
- something I just forgot as I went to write it and got stuck reading older shit here
|
|
|
|
- SCROLL POSITION !! - Very important, must return UI to exact scroll position on navigation backwards, not doing so causes a hellish UI to use.
|
|
- Seems to be a thing in teh vue router already:
|
|
- https://router.vuejs.org/guide/advanced/scroll-behavior.html
|
|
- Same position in window
|
|
- Same settings in any grids being shown and scrolled to same point in grids
|
|
- AUTOMATED UI TESTING - I need to institute it now and make tests so I have a template to work off for all future tests
|
|
|
|
|
|
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!!
|
|
|
|
|