ayanova/devdocs/todo.txt

@@ -66,20 +66,37 @@ CURRENT TODOs
 
 @@@@@@@@@@@ ROADMAP STAGE 2:
 
-BIZ OBJECT STUBBING
+BIZ OBJECT STUBBING FOR EXPORT TESTING
 
 
-todo: 
+Modify v8 export to have an intermediate form where user chooses options
-	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.
+	Add option to export assigned docs as attachments
-	go through all and check which ones need to be uniquified by checking db schema of v7 or biz rules maybe
 
-	go through all objects below in cases to see if they will be renamed or dropped or etc so don't create pointless objects
+Modify v8 export to export everything (at least teh wikiable and attachable and custom fieldable)
-	Consider making one of each of *all* Corebiz root object types but start with these ones first
+	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)
 	
 
-
+todo: PLANNING Look at attachment saving code on server, should it zip?
-* 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?
 	- 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