admin/raven-client
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
346713d22eaa44f659a347a4e0729fe26a35bb79
raven-client/ayanova/devdocs/todo.txt
John Cardinal 346713d22e
2019-11-12 23:37:57 +00:00

473 lines
31 KiB
Plaintext
Raw Blame History

# CLIENT TODO (J.F.C. - Just fucking code it already)
Success is the ability to go from failure to failure without loss of enthusiasm - Winston Churchill
"A smooth sea never made a skilled sailor" Franklin D. Roosevelt
"Every man has two lives, and the second starts when he realizes he has just one" ~ Confucius
BIG PLAN
1) Get the widget edit form completely working with the exception of reporting which can be stubbed out but should be present even if not functional now
- nothing left to determine, ready to copy to other objects and automated testing
- Test manually with all devices before baking it in
2) Scaffold the shell framework completely in place as much as possible so that we know there will be minimal other changes required
- All areas stubbed out now even if empty, just so you can see it and know what needs to be fleshed out and for demo purposes
- Test manually with all devices before baking it in
3) Get the Widget list and filter and any other options (except reporting) fully working and ready to roll out.
- Nothing left to determine, all done, ready to copy and automated test, with a stubbed out reporting UI
- Test manually with all devices before baking it in
4) Reporting - figure it out, flesh it out, make it happen
5) Licensing / Rockfish get this ready with Rockfish to be able to license it in reality so it's ready for 3rd parties
- Test the full trial / license business cycle and confirm it's solid and integrated into the Rockfish database properly
- Doesn't have to be perfect, just working enough for the real world, can make it easier or nicer later
6) Look for anything major missing at this point, make it deployable as a package and test the deployment on a raw server
- need to know it will be ready for 3rd parties to try out as much as possible.
7) Start adding the real shit and the corresponding v7 import code for that shit
- This is when the build and test cycle really starts hitting stride
- Goal at this stage is to build a testable deliverable on a regular basis with a new section of stuff added periodically
NEXT TODOS:
UPDATE vue CLI 3.x to 4.x , Vuetify 1.5 to 2.x (many breaking changes) and all the things before commencing work
https://cli.vuejs.org/migrating-from-v3/
https://vuetifyjs.com/en/getting-started/releases-and-migrations#migration-guide
https://blog.anoff.io/2019-10-migrating-vuetify-1-to-2/
https://github.com/vuetifyjs/vuetify/releases/tag/v2.0.0#user-content-upgrade-guide
GRID and other useful porting info:
https://blog.anoff.io/2019-10-migrating-vuetify-1-to-2/
=============== UPGRADING NOTES =================
Vuetify source code for components is here: https://github.com/vuetifyjs/vuetify/tree/master/packages/vuetify/src/components
** NOTE: can start dev server, go to *it's* client to see a working older version of ayanova client for comparision!
http://localhost:7575/login
http://localhost:8080/login
CURRENT WORK:
- Get edit form existing features completely working (also need new reportchooser not based on the original dialog component)
- Back to other items listed here after edit form working again
=================================================
DONE (for widgetlist grid and basic views): VIEW PERSISTANCE / STATE
- There is temporary SESSION DATA and PERSISTED SESSION DATA
- Some needs to go on closing session (login/logout) and some needs to stay
- Persist view on return
- useful info here: https://vuejsdevelopers.com/2017/04/16/vue-js-browser-button-ux/
- 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
- 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
- CODING:
- Need two types of page state, one that survives a logout login session and the other that is cleared
- For example, a user may want to always show 30 items in one list but 5 in another so this should survive login
- On the other hand the scroll position should not survive a session and should be cleared
- We don't need to worry about this for the pages in theory as there is a built in method used in router to enable it which seems flakey but it's the way to do it
- Focus only on the type that survives a session for now, the rest as required
DONE: ADD NEW WIDGET
- Add new record button to the edit form for a widget
- Hook up new record button on top of widget list
- Code for new record to the server
- Need a path to making a new record
- ID 0 maybe
DONE: New widget exposes issue with empty dates and the picker, it gives an error if the date is empty
DONE: DUPLICATE
- Make it work, maybe server should do the duplicating and just return a record when user selects this, a duplicate route
DONE (NEEDS re-test ON MOBILE for appearance and functionality): Reports - stub out
- Stub out some fake reports in a drop down selection for testing, doesn't have to do anything but be present
- Currently implementing as a dialog, either I need to follow the vuetify dialog example and put it in the shell app.vue or I'm going to use the dialog library I already have once I get an answer on templates
- If I use the vuetify example it means there needs to be a dialog in the shell that is activated from any form inside it but it also needs to be bound and shit and won't be very clean
- If I use the library dialog component and figure it out in theory it will just popup when required and not pollute the shell template with anything. I guess it inserts itself into the dom.
- I have a question in to the developer about how to do the example with templates here: https://github.com/yariksav/vuetify-dialog/issues/39
- The vuetify dialog example I would use is here: https://vuetifyjs.com/en/components/dialogs#form and the top one without activator here: https://vuetifyjs.com/en/components/dialogs#without-activator
DONE: For form initialization modify widget edit make an simple init call for onCreate
- Init should be promisified and have a chain of promises for form initialization so async stuff can properly finalize before init is done and code moves on
DONE: Turn widget edit ROLES into a static select populated from server
- Use the enumpicklist route to get a list of roles and use it for the widget UI
DONE: Widget - NOTES FIELD
DONE: TAGS!!!
- Implement and componentize
DONE: Server SEED DATA WIDGET CUSTOM FIELDS DEFINITION
DONE: WIDGET Customize menu item
- Make a menu item that shows in Widget edit form for users who are BizAdminFull only, title is "customize"
- this takes user to customize form where they can customize the widget form, set custom fields, maybe what shows or not etc
- this is to customize the form but it should contain a link to the locale text editor in case that's what they actually intend to customize
//DONE: Move all of my libs and code into the Window object under window.$gz(.local, .api etc)
TODO: BUG? If I open a widget record, make no changes just click on another navigation item like operations console, instead of navigating I get an error about object did not pass validation and it stays on that page
- It's trying to open this url: https://test.helloayanova.com/inventory/widget/edit/ops for some reason tagging ops on to the current route, not replacing the route entirely
TODO: SERVER STATUS
- check server status on attempt to login for first time or whatever, it should give a prominent warning if the server is unavailable due to closed for maint or whatever rather than just timing out.
- Also it allows login which is good but it should restrict the UI if it's a fresh login to a closed server rather than just failing to do certain things
- Maybe overall testing is needed with a closed server just to suss out what to do in the UI for that, we want ops people and admins in there but not other biz users if it's locked out
- Maybe an alternative page when it's locked out instead of the normal view of each view saying server down for maintenance or something
TODO: Would be useful to see and manage OPS things related to deployment to server just to save time, can refine them later
TODO: (may be done already) modify the inventory-widget-edit form initialization shit so that the stuff needed after form loads still happens but the before is moved to route before enter and that it's all called
with two separate methods: One standard one for init form before it is loaded and one for init form stuff for after it's loaded. BeforeLoadInit, AfterLoadInit or something
TODO: Custom fields
- Needs to cache the customization data of the form and concurrency token used to fetch it and then it checks the concurrency token periodically
- Needs to be aware of and handle the fact that the end user may change the data type
- if it expects a type of value and finds one it can't co-erce into the new type then it should zap it or set it null by default.
- This could get ugly so just stick to a simple system like wiping uncoercable data and fuck it, they made their choice :)
- Implement then Componentize
- Maybe start with a component first now that I have my feet wet in it, saves time
- Have to think about the design, but probably most useful when on the same page as the main record just like in v7 windows
- Should be a single component I can reference on the form that handles it all directly
- Custom field "slot" maybe just like the VUE Way so that it can be easily optionally shown or not in it's slot
- Though, these need to be part of the record as well, hmmm...maybe better if they appear to be just normal fields and are added dynamically??
- It would be nice though to just insert a slot and let a component handle it rather than buncvh of code on every form...
- It's kind of like one control that is bound to the JSON custom fields-field and it would update it as edited and required so I guess this is how to think about it and implement it, as a control
TODO: Form customize UI
- Where you create custom fields and edit
- If a user changes a field data type there needs to be a big warning before accepting it.
TODO: Support form customization beyond Custom:
- hide fields not used
- force user to enter a value in a field optionally that isn't already required
TODO: Record history display / check other AyaNova 7 options / buttons that need to carry forward
- implement and componentize
- Record history could be displayed on a timeline: https://vuetifyjs.com/en/components/timelines
- Make sure it's scrollable maybe and doesn't take up too much space
- Defaults to showing most recent stuff first in order to satisfy most common requirement of who last edited
- Probably going to need a server route but let the UI drive it (timeline view requirements maybe?)
- Record history "slot" maybe just like the VUE Way so that it can be easily optionally shown or not in it's slot
TODO: WIKI
- componentize
- in vue slot? or separate page, probably separate page as it will need full screen likely for most users
TODO: Attached documents
- componentize
TODO: save and new button in edit form like v7? Or only from main?
- will the menu be too crowded?
RETEST HERE ON ALL DEVICES
TODO: NOW THAT FORM IS THERE MOSTLY, CLEAN UP CODE FOR RE-USE in many other forms
- Look for things to componentize
- Look for things that are not specific to the widget edit form but can be abstracted away for other forms
- Don't need to replicate common code so put it somewhere else
- Are any of the controls better as a component and self contained to save the size of the form code and complexity?
- What I mean is, for example, a text entry field could be standardized then re-used as a component if it's props and settings take up so much space etc
- 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: Outstanding case with vuetify bug in clear button when readonly, check if fixed and if it isn't might need a workaround
TODO: Document in user manual the Widget form as an example with instruction on how to use the various controls etc
- "Anatomy of a AyaNova Form"
TODO: AUTOMATIC TEST
- Once widget form is solid then need an automatic UI test for it to get that ball rolling and to ensure no slips during development
- Ideally it will test every input component and validate the entire record round trips properly, maybe it needs to also try different states like creating new, editing etc
TODO: Server needs to do widget validation 666.66 dollar amount test rules not only in debug mode so can test when put up to the devops server
- Test code is in widgetbiz.cs around line 445, but do we need it? Maybe just find a proper server error that can be made to happen naturally?
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: INVESTIGATE / REDO THE TOP LEVEL SHELL - TIME TO MARKET / Is my shell layout fucked?
- wouldn't it just suck to have all those lists exposed at once in inventory?
- Opening that page once they are all there would trigger huge traffic to the server, better to confine things to their own area as much as possible
- TTM: isn't it faster to just turn the menu into a tree like v7 or put options in each one's screen? (Like inventory page just shows a bunch of other icons to open details like widgets)
- TTM: I'm concerned that the modular UI is a bit too ambitious, yes it makes sense for re-usability but exposing it to users so they can redo their UI seems crazy ambitious at this point
- People just want to work and simpler is always better, less to maintain
- How about the easiest simplest layout possible even if it's a bit uglier but keep it all clean and focused instead of too much shit on each form?
- Really, for maintainability it makes sense to have a very simple clean layout and not try to put a bunch of complex controls all over the fucking place!!
- I need to make money from this, not win prizes for design!
- Easier to show or not things for authorization purposes when they are each in their own navigation path as much as possible
- users are used to a certain thing with v7 why re-invent the wheel, just clean it up and modernize where necessary
- There are so many other things I need to focus on, this is just adding complexity in an area that might be a nightmare to maintain and troubleshoot.
- DON"T get too fancy with this, my instinct is to make it more complex all the time, but actually ugly and simple and effective is better than pretty but fucky to use
- Also, mobile really doesn't go well with fancy but more with clean and simple.
- Sounds like my minds made up, this issue is more about changing the SHELL UI
- IDEAS:
- old fashioned switchboard kind of thing, big buttons for each area sit in a row, on mobile they are vertical full width?
- ugly but effective
- Alternative is a Tree control in menu instead, but that would likely be ugly in mobile(could investigate but it's not common probably for reason, look at material apps on phone see what they do)
- Don't worry about having to navigate too deep with too many clicks for the top level, yes some won't like it, but it's more important to focus usability and minimizing clicks in the actual path that day to day users take
- In other words make the most common tasks quick to do from the top level / HOME screen perhaps and *thats* where to focus on customization so users can surface what they want there as a LINK
- Users can modify what shows by default in the home screen but not the fancy active widgets I had envisioned but instead different task based buttons / links so they can get to where they need to go quickly
- e.g. click on inventory, select the Widgets switchboard button, the widgetlist opens full screen to the right side, one of the menu options is "Add to home screen" with a favorite button
- They click on add to home screen and next time they are on home screen a new button / link is there to that item, autoamtically pre-grouped by area of functionality or maybe they can just order it how they see fit?
- I really like the idea of the widgetlist being full screen to the right rather than in a component sharing that space as it's pretty necessary
to have a lot of columns display at times, yes it's a ui made up of a bunch of lists but that's really what people understand, it's appropriate to the application,
no business software can simply hide everything and it doesn't have to suck or be ugly
TODO: Automated testing of UI by driving web interaction, that needs to be instituted asap
- However, until the shell is worked out it might be best to hold off, that's why I put it below the shell stuff above
TODO: INVESTIGATE - Dark mode / theming (dark with a half moon icon)
- If it can be done with a half hour of work and doesn't affect anything support wise or maintainance wise then yes
- Also see how to allow theming maybe or colour choices? Nah, dark mode is the most useful; I should decide the colours and stick with them it's part of our image
TODO: INVESTIGATE - Grid / LIST VIEW COLUMNS SELECTABLE?? 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
- they will also want to set the order, maybe that's not going to be supported though
- 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??
- Security and business rules may affect this as well, for some users they have rights to some of the record but not all of it, i.e. subcontractor so we do need granular field level control over what goes out from the server and at the client expectations
- Maybe list objects also return a list of fields the current user will expect to see so the list can be pre-set up with the columns at the client *then* the data fetched to populate the list
- Server should not send fields that are restricted or have them blocked out or something.
DONE: Grid list view should be easier to open, the open button should not be at the far right but more of the whole entire element or a larger portion of it maybe?
TODO: List view FILTER button
- Get it working
TODO: Grid list STUB OUT other options
- Put in the menu options will likely need even if not coded yet.
- go through cases find the new things that need to be on the menu and stub them out.
- Stub them out so they are there even if not functional
- Maybe make all stubbed things an alt colour so can tell at a glance what is outstanding.
- Reporting, list mass ops, go through cases look for stuff that will be required
#locale stuff
TODO: //todo: timezone doesn't match, offer to fix it in initialize.js there needs to be a prompt and autofix
TODO: code the user options with the currency symbol etc on the server and then update client to fetch them. 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)
TODO: Local user settings page / UI where can
- set locale choices and values
- Reset to default form settings
- Other shit I can't think of right now but there will be a lot
TODO: License trial handling front end code to make my life easier
TODO: Add formstate data to technical support information
TODO: Need to do all outstanding edit form stuff next
### RETEST ALL DEVICES WHEN GET TO HERE #####
TO TEST:
- above changes block
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
- 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
- Maybe an issue maybe not: On field change and lose focus, the save button is not enabled necessarily until the second click
- Can the save button be enabled more quickly after losing focus on the edited field or should I revamp that?
- I can see users making a quick change clicking on save once and it won't save but they think it has.
- Right now you need to click twice on save
- 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!!
*********************************************************************************************************************************************************
## TODO...MAYBE??
This is stuff I thought of but is dubiously necessary for the initial release at least or could be polish added later:
TODO: Form dirty indicator on the form and easy to see, maybe the background tinges or something
- Save button kind of is, do we need this?
TODO: Trial mode client should offer alternative logins right on login page and fill in for user to try out
- So a list of user names and a short text of what that user is used for when testing
- User can select and it will prefill in the form
- Obvs when not trial mode then the client doesn't offer it
Reference in New Issue View Git Blame Copy Permalink