diff --git a/devdocs/todo.txt b/devdocs/todo.txt index 7ac264fa..8daff3cc 100644 --- a/devdocs/todo.txt +++ b/devdocs/todo.txt @@ -7,155 +7,21 @@ Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOiIxNTQ0NTU5NzAwIiwiZXhwIjoi 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 +Do the stuff in the Client todo first then back to the server as required. ----------------------- -/// -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!! +SERVER + - JWT issues?? + - potentially lots of issues, look into it as using them kind of mindlessly right now. + It could be simply that people are attempting to do other things I am not but to be safe read the criticism and see if any of it applies: + http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/ + https://stackoverflow.com/questions/27301557/if-you-can-decode-jwt-how-are-they-secure/27301616#27301616 + https://news.ycombinator.com/item?id=14292223 + https://news.ycombinator.com/item?id=18804875 + - PASETO instead of JWT?? + - https://paseto.io/ @@ -179,6 +45,13 @@ DEVOPS + + + + + + + =-=-=- some shit I probably don't need anymore: