admin/raven-client
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Browse Source
This commit is contained in:
John Cardinal
2020-05-01 23:55:10 +00:00
parent ce93b3eedb
commit cec9fd0934
1 changed files with 28 additions and 91 deletions
Download Patch File Download Diff File Expand all files Collapse all files

119
ayanova/devdocs/todo.txt
View File

@@ -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<string> 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 {
/// <summary>
/// Not set / unused
/// </summary>
Unknown = 0,
/// <summary>
/// A single service workorder for a client
/// </summary>
Service = 1,
/// <summary>
/// Used by PM system for recurring service.
/// </summary>
PreventiveMaintenance = 2,
/// <summary>
/// An estimate provided to a client for approval that if approved gets copied to a
/// Service
/// </summary>
Quote = 3,
/// <summary>
/// A TEMPLATE single workorder for a client
/// </summary>
TemplateService = 4,
/// <summary>
/// TEMPLATE Used by PM system for recurring service.
/// </summary>
TemplatePreventiveMaintenance = 5,
/// <summary>
/// An TEMPLATE estimate provided to a client for approval that if approved gets copied to a
/// Service
/// </summary>
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