raven-client/ayanova/devdocs/todo.txt

# 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: 
	- DONE Delete works but triggers navigation guard when record has been edited and is dirty and it attempts to navigate away after deletion automatically
		- Dirty delete should clear dirty after successful delete then move away or whatever
	- DONE About form when you go to log doesn't update the title bar showing log, still seems to say about ayanova

	- EDIT_OWN: HOW TO HANDLE PROPERLY??
		- TechFull user should be edit own but can't navigate to inventory form to test when not going directly from a link ?!
		- Same issue with BizAdminLimited and read only, can't go to inventory at all to view list
		- rights must be set for only full access to even view the inventory page.
		- RETEST RIGHTS after this because could not test with this issue
		-  this is the code block affected: if (
            roles.hasRole(roles.AUTHORIZATION_ROLES.InventoryLimited) ||
            roles.hasRole(roles.AUTHORIZATION_ROLES.InventoryFull)
          ) {
            addNavItem(locale.get("Inventory"), "dolly", "/inventory");
          }
		- This is all an issue with EditOwn rights, maybe I should consider zapping that entirely as a feature, why do I need it again????
			- relevant info:
			- C:\temp\xfer\v8 research stuff\JoyceAyaNova8stuff\1_REVISIT_2014-06\1_User_Roles_records\1_Roles.odt
				- See "TechLimited" role for deets
					- Tech-Limited
						• suggested use:
						• for tech that can view all views except Profit/Loss
						• access to Info, To Do, Completed, Materials & Service, Quote if there, Invoice if there
						• can not generate quote, can not generate invoice
						• can not edit their Scheduled item fields (who scheduled, when, est), but can add the labor with it
						• can add workorder components (i.e. parts, loans, etc) but can not view costs
						• can create new client, can create new unit
						• can only edit client or unit that they themselves created
						• Can view service history, PMs,  of client/unit
						• Can only edit Open workorders where they themselves are scheduled.
						• What can edit, refer to WorkorderRoles doc ???
			- https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1782
			- https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1809
			- EditOwn is originally intended to deal with limited rights users who are not supposed to see other workorders but the ones they are supposed to work on.		
		- ISSUE: if they can only edit own widgets but not create or change others, do they still see the list of widgets?
			- How do they create one, are they allowed to?
			- What role allows create but not edit or is that a thing?
			- WTF?
			- This is to support users that are limited to their own records in order to privatize general things as people have requested.
				- They want users to only be able to see some limited things
				- The plan was to allow edit own, but that seems to be a can of worms because
					- How to show a list
					- Can they just create without the list?
					- Can they view their own in a list?
					- Is this above roles in some way or part of them?
					- Can the server just show a list of self-owned?
					- Can the client check a right and decide that since they can edit own they are allowed to see that feature section  but it might be empty?
					- This seems wonky to me right now but maybe it isn't, it's been an idea for some time but maybe not really questioned in reality scenarios.
					- Edit own is only about workorders?  Or everything?
					- Issue is that this means every possible way of viewing widgets for example needs to have exceptions for people of limited roles who are only supposed to see their own widgets that they created.
					- Does this mean every list fetcher needs to check rights first then add an additional filter if they are only allowed to editown restricted to owner=currentuserid?
						- Would that solve this problem?
					- Is this only about workorders or other types of records??
					- Maybe it's as simple as adding an automatic filter to the getmany routes in bizobjects that add if editown and filters on ownerid=currentuserID
				- Plan calls for limited users to be able to create a client for example to fill out a workorder even if they are a subcontractor with limited client rights but this seems bogus, the requested feature is probably more to do with they can fill it out but not create major new objects, only select from them.
		- POTENTIAL SOLUTIONS
			- NAIVE SOLUTION
				- Just add more code to show the editown able stuff in addition to the full or limited rights
				- Add more code for all getmany lists to auto-filter on own if that's the only right.
			- A new right for does the user have ANY access to an object for the client to quickly check and show sections / lists?
			- GetMany list object checks if only right to that list is editown and then adds a filter automatically to only show ownerID=currentuserID
			- Client checks not only full and limited but also edit own and if there is any editown then allows to continue
				- Potential issue here: do we show all of inventory if user only has editown rights to widgets and not parts (for hypothetical example)
			- Re-think the editown system, what exactly is it solving and is there another way to accomplish that?
				- For example if it's only about workorders then 
					- Can we stick to the Change and Modify rights and just have the ability to assign workorders to lesser rights users user by user?
						
				- Does edit own even work?
					- For example, this means that a user needs to OWN a workorder to be able to edit it if they are subcontractor, that's NOT how it would happen in reality dispatcher would make it
					- The roles source docs say the user must appear on the workorder to see it.
					- Maybe it's more of a right thing that has nothing to do with editown and more to do with relevancy, so...
						- A service workorder is relevant to a non roled user if they appear on it even if they are a subcontractor
							- However they only see the bare minimum they need and nothing else.
			- Limited rights user can only select existing items to fill out a workorder? Not create new?
		- STEPS TO RESOLVE THIS:
			- PLAN: Is this an impedence mismatch between roles and sections in the UI?
				- For example a role can have the ability to see a section of the UI but in that section some might not appear
					- I.E. Widget is under Inventory section which is nebulous and not defined anywhere formally so cant' check in code
					- But also parts are inventory but user may have no rights to parts so that's a sub part of the inventory section to be checked
					- UI needs to know does user have *any* rights to this area and then show it and then each sub item checks the roles to see if a list of parts (for example) should show?
					- So need a quick checker to see if any part of a section is showable maybe that is a separate system from roles
			- READ: Go through plans and docs and look for roles related stuff and also subcontractor stuff to get a feel for what needs to be supported first before getting any deeper into this
				- Maybe I don't have the full idea of what this is about
				- Is this mostly subcontractors or is this also limited techs with limited rights?
				- Maybe I can have full techs do anything and limited techs only fill out forms, not create?
			- REQUEST: What is actually being requested by users to fulfil this feature that is different from v7?
			- SCOPE: Figure out what objects this would even affect, maybe it's only the workorder
			- TTM: We don't want to hold up all of AyaNova 8 over this, the default mode is to do what was there before in v7, is this worth holding everything up?
				- Can it be a future feature or does it need to be in v8?  Probably needs to be in v8
			- Can this be worked without any editown features?
				- Why does a user with limited rights get to "own" anything?
				- Aren't they just a "filler outer" of forms and not a creator of anything?
			

			 


	- About page - should show currently logged in user name, doesn't actually show anywhere right now
	- LOGIN: hitting enter / return should be equivalent of clicking on OK button
	- Not actionable but FF is super slow on Lenovo and had to reset and reload multiple times to get to the app, but it did update almost immediately once it was loading.
		- Also the icon is still showing the old outdated favicon, didn't reset, slow and fucky, app works though, no issues
	- Pixel ONLY, not on any other platform: Chrome AND FireFox as well - went through stuff, when I went to about page then attempted to select LOG from menu I noticed ??Log was showing for log
		- In the log it was ok at the top and backing out and back in Log showed properly in the menu from the about page so it seemed to refresh when went into the log
		- TODO: Check if ??Log is fetched on About page or prefetched or where it's fetched and is it doing it properly with a Promise Chain
	- On pixel probably all though: 
		- Selected 420 in the widget edit form but it shows as 11:20 on the main list, localization time issue
		- Retest on desktop, probably a general date time conversion bug
	- Some devices showed still logged in and outdated version so concievably could keep working in it with wrong version
		- Figure it out
		- Ideally it should logout on version change, wipe local data maybe
		- Maybe also look into auto logout if it's been a certain length of time from last usage of AyaNova?
	- Failed login delay works as designed, but kind of long if you just typed it wrong, maybe look at reducing the delay a little bit
		- Any delay is significant for a password hacker but annoying for a user who mistyped
	- 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
	- On object not found when deleting an item and trying to reload the edit page, shoudl redirect to home or back instead or just not there


### RETEST ALL DEVICES WHEN GET TO HERE #####


End to end action

TODO: LOGIN navigate back to prior request when it triggers a login?
	- Or would this cause a loop at times and fuck shit up?
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!!