diff --git a/ayanova/devdocs/todo.txt b/ayanova/devdocs/todo.txt new file mode 100644 index 00000000..c0121a63 --- /dev/null +++ b/ayanova/devdocs/todo.txt @@ -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!! + + diff --git a/ayanova/public/index.html b/ayanova/public/index.html index 778c7b27..f0d1bba1 100644 --- a/ayanova/public/index.html +++ b/ayanova/public/index.html @@ -5,7 +5,7 @@ - ayanova + AyaNova