PRIORITY - ALWAYS Lowest level stuff first =-=-=-=- todo: check non-ops user can login during seeding operation todo: BizRoles.cs seems to get hammered on every single request, is it efficient? - Why is it not cached in some way? - Look into Lazy initialization (i.e. private static readonly Lazy> mappings ....etc) - Maybe break it out into separate objects if do so then ideally put them into the biz object responsible? - it has to instantiate that anyway on any meaningful operation or...is this worse than actually caching in a lifetime cache because it will need to load on every route hit whereas a lifteimte cache is just there from being loaded once? todo: API REFACTORING (note: workordercontroller / biz should be following all these rules so it's the template if need reference) todo: consider and then get rid of PATCH in all routes unless compelling reason to keep Would there be a place in the UI where I would want to patch part of an object? Because I already ditched that for the workorder which is the heaviest and most patchable object in the bunch if I change a name would I patch it or just put the whole record? supporting it only for the use of third party users is not a good idea todo: consider renaming ConcurrencyToken to a shorter string? todo: all api route parameters, post object sb "newObject", put="putObject" IN BIZ TOO todo: all api routes, re-arrange code in controller in this order POST (and postlike such as duplicate), GET, PUT, DELETE for consistency and logicality BIZ TOO todo: all api route URI's sb lower case with dashes if necessary (use plural noun scheme) https://docs.microsoft.com/en-us/azure/architecture/best-practices/api-design#organize-the-api-around-resources todo: Controllers should not need to know about databases refactor code so controller never fetches or deals with saving an object, all that is biz responsibility todo: Routes should check rights *BEFORE* they fetch the object, not after, all routes affected i.e. delete route instantiates biz object, then it fetchs object from db *then* it checks if they have rights to delete (generically, not specific to that object) This is out of order as it triggers a db call even if they have no rights to do it todo: all biz objects "ExistsAsync" is this required / necessary? todo: add query fail logging to datalist just like done with picklist so in production can catch mysterious problems more easily todo: AUTO ID GENERATOR change to a dedicated spot in global rather than inferring as it is not right practically for reasons Get the auto-id most recent values at boot time internal static void SetMostRecentAutoIdValuesFromDatabase(AyaNova.Models.AyContext ct) 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 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: 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: 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: 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: 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.