admin/raven-client
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
cb9175d2066802e87be27e5c4b9d6bbb9e160639
raven-client/ayanova/devdocs/todo.txt
John Cardinal cb9175d206
2019-05-02 22:55:50 +00:00

336 lines
21 KiB
Plaintext
Raw Blame History

# 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
All platforms and browsers
- IN PROGRESS: Initially outdated, had to force a refresh to make it load the latest version
- STATUS: I'm going to do another update and see if it's handled properly
- I thought they would update automatically via the loader code?!?
-
- DONE: Login user name field auto capitalizes first character on phones, need that to not do it
- DONE: Login, doesn't have any ui if failed login, maybe a red frowny face icon? :)
- DONE: need clear buttons on pw and login
- DONE: Numeric input fields don't give numeric keyboard
- DONE: MENU STUFF
- DONE Global Help link on *every* page
- will change on each page
- DONE Global Logout link on every page
- Unchanging
- Probably more global page items
- DONE Menu supports dividers
- DONE Menu has a context section and a global section
- One set of menu items only not two separate ones internally
- Context items are at the top, then a divider, then the global ones at the bottom
- DONE Caller sets if it's contextual or not to adapt colour of app bar, but otherwise it's the same exact menu all the time
- DONE Caller should be able to set items colour so (for example) Save can be redded out when not savable
- DONE Caller should be able to set the ENABLED property so it can handle different states
- DONE: Maybe a change item event that takes a key and updates it rather than refreshing the whole menu basis on state change?
- I.E. so that can change save button enabled and colour when state of form broken rules changes?
- DONE Surface property that will force an item to be surfaced to the left of the menu in the app-bar
- Keep the original in the menu though for people that are used to it?
- DONE reorganize SAVE, DELETE ETC, put a divider between main form actions and then all the myriad of secondary things
- DONE LOCALIZE check all new menu items, some might be not localized (look for ALL CAPS)
- DONE WIRE UP logout link to go to login form and logout properly
- DONE JUST CHANGED the keys to a new system and dropping data property, right in the middle of it actually but it needs to be changed back partially see below
- DONE First of all, put gzmenu on to the vue object in main so can use it for little utilities like click handling, generating unique nav keys etc
- DONE Reason was to ensure key uniqueness (two nav items with same key are erroring)
- DONE HOWEVER as I'm thinking about it now, do we really want all that url stuff being in the key?
- DONE Instead, change back to using data but add a third parameter to make sure that keys are unique somehow
- DONE That way we can put anything into the data key again because in future might need whole objects etc (almost certainly will)
- DONE Move ABOUT item to just above HELP in menu and remove from main NAV and make it navigate properly on click
- DONE Make about contextual and insert a menu item to view log
- DONE WIRE up save menu item and add code to disable save on broken rules (and make red, disabled etc)
- DONE Move wire up event code from app.vue to gzmenu and call it from app.vue
- DONE RIGHTS in form state so can easily enable / disable etc
- DONE INFO - SERVER will return on request of an object one of these:
- DONE Not authenticated at all 401
- DONE Redirect to login
- DONE Not authorized for this object 403 (could be due to not own or whatever, we don't care, server handles that shit, client just knows not to show it)
- DONE Object...BUT with READONLY flag of some kind present (in outer wrapper??), so client knows to show read only and not allow editing
- DONE And client doesn't need to work out self owned etc
- DONE Object without readonly flag present so fully editable!!! WOOT!
- DONE If no rights then should redirect back to HOME, NOT LOGIN!!!
- DONE user with no rights = SubContractorLimited
- DONE BIG TODO: it would be far nicer if rights to objects were stored in a single JSON fragment that could be easily copied into javascript and c#
- DONE code automatically builds rights collection from json fragment so can use it between both projects and more easily update it in one central spot
- DONE Get that working then come back to the rest of the rights in client side
- DONE ALREADY Need to create sample users in server project that have all the different widget right combinations for testing purposes
- DONE HOME not localized issue, on login, sometimes the home page is not showing as localized! Some kind of timing issue or wrong event used to localize it or something. ??
- DONE I see that HOME->BeforeCreate breakpoint is hit **BEFORE** the locale text has been fetched.
- DONE was not calling promises correctly and not chaining them properly. Fixed
- DONE Wire up delete menu item
- DONE api code is stubbed out for delete, need to write that as well
- DONE Need prompt, are you sure??
- DONE TODO navigating through menu doesn't "back" properly when clicking back on browser controls
- DONE widget form now not localized title at menu top
- DONE Edit form title, does the edit form need a title so users know where they are at?
- DONE currently widget edit doesn't have a particular look or title so if you are at the top of it on a small device you can't see the url fully or really know which page it is
- DONE A small title top left that stands out might be approprpiate, also a icon beside it?
- DONE: Application name is all lowercase "ayanova" when installed to device, must be something in the manifest files?
- DONE: Check about page localization code, is it firing in the right place because on Edge and iPad firefox it didn't show localized at first until a refresh so it fetched the keys but didn't display properly
- TO TEST: Calendar on iPad in two occasions with ff and opera the calendar date could not be selected until a time was changed then the date worked. Before that it would always stay the same no matter what selection was made and the UI would not show a change on select or press of date either.
- DONE Navigation guard: navigate away with unsaved changes should warn and prevent but have option to continue anyway
- DONE Logout needs the same request
### 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!!
Reference in New Issue View Git Blame Copy Permalink