From cec9fd093487e1278e59801bd05e75bfa0529b4b Mon Sep 17 00:00:00 2001 From: John Cardinal Date: Fri, 1 May 2020 23:55:10 +0000 Subject: [PATCH] --- ayanova/devdocs/todo.txt | 119 +++++++++------------------------------ 1 file changed, 28 insertions(+), 91 deletions(-) diff --git a/ayanova/devdocs/todo.txt b/ayanova/devdocs/todo.txt index 21e2a9e2..1693eab5 100644 --- a/ayanova/devdocs/todo.txt +++ b/ayanova/devdocs/todo.txt @@ -66,20 +66,37 @@ CURRENT TODOs @@@@@@@@@@@ ROADMAP STAGE 2: -BIZ OBJECT STUBBING +BIZ OBJECT STUBBING FOR EXPORT TESTING -todo: - remove duplicates to get to one list, go through each at a time, check if retained or renamed then add to the Make these list. - go through all and check which ones need to be uniquified by checking db schema of v7 or biz rules maybe +Modify v8 export to have an intermediate form where user chooses options + Add option to export assigned docs as attachments - go through all objects below in cases to see if they will be renamed or dropped or etc so don't create pointless objects - Consider making one of each of *all* Corebiz root object types but start with these ones first +Modify v8 export to export everything (at least teh wikiable and attachable and custom fieldable) + Uniquify: go through all and check which ones need to be uniquified by checking db schema of v7 or biz rules maybe + this is a v8 export plugin concern, not a RAVEN server concern + MIGRATE these deprecated things off of a USER object created just to host their stuff (user because only biz admin has full rights to user) + Put them in an INACTIVE, NO RIGHTS User with the following + Global - wiki, files -> User "V7_GLOBAL_WIKI_REPOSITORY" + Region - wiki, files -> User "V7_REGION_WIKI_REPOSITORY_regionnamehere" this is preliminary as there is a ton of other shit to import from region into various other areas but it has a wiki so that should be dealt with -Note: "Files" refers to wiki embedded as well as, optionally exported, Assigned docs -Note: Uniquify is required for porting some objects that in v7 didn't enforce unique names -* PORT these objects to RAVEN: + + + + ============================ + +todo: PLANNING workorder data and class and route structure: + A biz object for each one? + probably need the parent for biz rules and shit so likely best to keep in one file + Controller - all in root controller or seperate controllers? + likely follows biz object decision + Use foreign keys!! + +PLANNING Workorder templates + Keep as is or...? TTM!? + +todo: locale keys for 22 objects brought in, some need renaming //Client -> Customer (wiki, files, custom fields) Contract (wiki, files, custom fields) HeadOffice (wiki, files, custom fields) @@ -103,87 +120,7 @@ Note: Uniquify is required for porting some objects that in v7 didn't enforce un Workorder (pm template) -> PMTemplate (wiki, files, custom fields) - -* MIGRATE these deprecated things off of a USER object created just to host their stuff (user because only biz admin has full rights to user) -Put them in an INACTIVE, NO RIGHTS User with the following naming scheme: "V7_REGION_REPOSITORY_regionNameHere" "V7_GLOBAL_REPOSITORY" etc - - Global - wiki, files -> User "V7_GLOBAL_WIKI_REPOSITORY" - Region - wiki, files -> User "V7_REGION_WIKI_REPOSITORY_regionnamehere" this is preliminary as there is a ton of other shit to import from region into various other areas but it has a wiki so that should be dealt with - -Basic class: - public long Id { get; set; } - public uint ConcurrencyToken { get; set; } - - [Required] - public string Name { get; set; } - public bool? Active { get; set; } - public string Notes { get; set; } - public string Wiki {get;set;} - public string CustomFields { get; set; } - public List Tags { get; set; } - - - - -WORKORDER CHANGES -Raven to have separate objects for each workorder type, and seperate db tables etc -This will make coding life easier and better performance -Also can then diverge the objects considerably over time without UI gymnastics - -CANDIDATE OBJECTS: - - - - - -public enum WorkorderTypes : int { - /// - /// Not set / unused - /// - Unknown = 0, - /// - /// A single service workorder for a client - /// - Service = 1, - /// - /// Used by PM system for recurring service. - /// - PreventiveMaintenance = 2, - /// - /// An estimate provided to a client for approval that if approved gets copied to a - /// Service - /// - Quote = 3, - - /// - /// A TEMPLATE single workorder for a client - /// - TemplateService = 4, - /// - /// TEMPLATE Used by PM system for recurring service. - /// - TemplatePreventiveMaintenance = 5, - /// - /// An TEMPLATE estimate provided to a client for approval that if approved gets copied to a - /// Service - /// - TemplateQuote = 6 - - }//end WorkorderTypes - - - - ============================ - -todo: Workorder type objects children and grandchildren - A biz object for each one? - probably need the parent for biz rules and shit so likely best to keep in one file - Controller - all in root controller or seperate controllers? - likely follows biz object decision - -todo: locale keys for 22 objects brought in, some need renaming - -todo: Look at attachment saving code on server, should it zip? +todo: PLANNING Look at attachment saving code on server, should it zip? - pros and cons? --------------------------------------------- @@ -218,7 +155,7 @@ todo: change trial detection route that client first hits - maybe the route that gets Notifications - because there could be a notificatoin type that doesn't need logged in users for general server down announcements etc -todo: session tracking to prevent logging in from multiple devices with same account +todo: PLANNING session tracking to prevent logging in from multiple devices with same account - right now if I login as same user on another browser the download token becomes invalid on the first computer - so wiki images don't load etc - Perhaps we track the download token or something during certain requests to server so it can return a 403 and redirect to login if they are on another session