PRIORITY - ALWAYS Lowest level stuff first
=-=-=-=-

todo: Search get search result for workorder descendents doesn't fit into existing system due to it being a biz object wide feature but workorder having sub-get results
		- CHILD objects need to point to their parent and be readable in code for searching and for opening objects based on child object
		- so all child objects need a typeandid of the immediate parent
		- Not sure where to document this so putting it here for reference
		- Required for opening a search result of a descendent that is not directly openable an
		- Need parent AyaType as an ENUM ATTRIBUTE in the AyaType table for easy traversal
	ACTION:
		I think simplest and most effective would be a route / public static biz function that will get the openable ancestor of a type and id
			Workorder graph are all search indexed by their exact type each
			When search comes looking for a result it grabs the exact type
			Search result list will have exact type
			Only needed to open the parent item
			So client sees a type that is not directly openable and queries server for ancestor / principle to open
				In Client, navigating to exact item e.g. a workorder item part is a client ui issue really
				The only issue related to the server is getting the top most parent openable object, the workorder in this case
				the rest can be done at the client easily
		Add Search controller route: ancestor(ayatype, ayaid) returns type and id, if no higher ancestor returns what came in
			this needs to be a central route, not tied to an object though objects can handle the inner workings maybe i.e. wokorderbiz for workorder tree , pobiz for po tree etc


todo: search tables in schema, I think there is a missing index here, need to look at the search query section again as it was changed several times from the original schema creation
todo: schema, move all initializing stuff to schema update 1
	right now it's 11 but that's weird

todo: tags - does server ensure only unique tags are saved even if there are dupes in the list?

MASS TAG OPS
NOTE: separate routes for seperate things just to avoid issues, i.e. dont' conflate two different functions in same route
	i.e. search and replace, not search and remove 
NOTE: no mass tag op route will work with every object in order for safety, there arent' *that* many objects so safer to have people pick them from a list and if they want they can manually check all types
note: they can use a datalist to select so no need to add any filtering ability here

todo: SET TAGS ability to mass tag items from list (SERVER AND CLIENT)
	route: mass tag by type and id collection
	route: mass tag by type and all objects no id specified

todo: REPLACE TAGS
	route: mass replace one tag with another tag by type and id collection
	route: mass repalce one tag with another tag by type and all objects no collection

todo: REMOVE TAGS
	route: mass remove specified tag by type and id collection
	route: mass remove tag by type and all objects no id specified

todo: API root controller
	build mode and server info should be authorized shoudln't they?  Unauthorized people have no need to see that stuff
todo: api / server landing page is shitty on a mobile
	and really just shitty, add a logo or some shit
	todo: Should server show uptime somewhere?
todo: Log configuration into server log at startup?	https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3523
	log all config settings into server log on boot
todo:aycontext clean up old block of weird definitions
todo: apiokresponse returns readonly value every time, but I check it anyway at the client and biz object itself doesn't set it I don't think, so...should it be removed?
todo: Is there a log that records past jobs, how long can they be viewed?
todo: Rename the link to AyaNova App on the server page to just "AyaNova"
todo: translation cjkindex, no way to set this value currently
todo: With removal of Closed button from Workorder a lot of peripheral things would be affected like notifications triggered on close
	Those will need to be adjusted to status of closed	
todo: Licensing - make sure tech type use license works properly: a tech license is consumed if a user has **any one** of the four roles of TechFull, TechLimited, SubcontractorFull, SubcontractorLimited
todo: OPS routes (SERVER AND CLIENT)
	- Backup, restore https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3369
	- These need to be done fairly early on in order to have shit to play with for testing etc
	BACKUP & related stuff that should be in v.initial release https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3369
todo: (BREAK THIS OUT INTO LATER/NOW/CASES) there are several outstanding AUTHENTICATION related cases in rockfish for RAVEN
	e.g. https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1924
	https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1835
	https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1998 <---this is an important case for consideration
	https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3367 <--time limited accounts for support or temporary access?
	https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/2059 <--- time restricted accounts so user can only login during business hours (still to be considered)
	2fa stuff, some logging and lockout stuff
	Go through the auth related cases and notes in client side and implement or close
	todo: 2fa? (if not in first release, is there something needed to support it in future dbwise?)
	todo: Auth Backdoor reset password feature
		how to code it here, pretty easy to do:
		https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3250
todo: Look into 2fa
	https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3395
todo: look into how to use an SSL certificate with the RAVEN server directly when not behind nginx
	- this should be supported by default out of the box working with Let's encrypt ideally
	- is it now considered ok to host .net core web api directly internet facing?
todo: onboarding and default manager account password
	- Need to come up with a safety plan for this so people don't leave it at default
	- Maybe the very first thing required of a user is to change the password before any tasks can be performed
	- Server stays in safety lock until they set a password?
	- Or maybe a random password is generated on seeding and somehow provided to user through console or something?
	- Maybe an empty db if no other users can be set password only so no one has made a hidden backdoor user account before ops changes it?
	- maybe tied to license if licensed so they bring some info they have from rockfish / their license purchase or something?
	- don't want it to be onerous too much and have some very inexperienced users so...
	- see what other programs do, like our forum software
todo: API docs, make separate page for datalists and remove from api-response-format.md doc but put a reference link to it there.

