ayanova/devdocs/todo.txt

@@ -188,11 +188,15 @@ todo: many biz objects are not using new PUT methodology
 
 CURRENTLY DOING: workorder (status)
 
-todo: workorder status first, it's a table of created items, keep properties from v7 but add the following properties:
+todo: workorder status list first, it's a table of created items, keep properties from v7 but add the following properties:
 	??RolesAllowed - who can select the status (still shows if they can't select but that's the current status, like active does)
 		But then anyone of another role can just change it to another status so this doesn't really control anything, just prevents being used by some
 		and adds hella overhead to the status picker lists / they would need post processing of some kind I think and lots of biz rules but doable
 		(can a query where clause work with a bit field? Yes: https://www.ehfeng.com/querying-bitfield-with-sql/)
+		Ok, so with being able to query on roles (theoretically), it's not actually as hard as I had originally thought, so this remains a viable thing
+		Actually, perhaps this is best handled at the client.  It prefetches all the status out of the normal picklist process, more like how other things are separately handled now without a picklist
+		client then knows if a status is available or not and can process to only present available ones
+		Server can use a biz rule to ensure that it can't be circumvented
 	FinishedStatus bool - this is a final status indicating all work on the workorder is completed, affects notification etc
 		Do I need this?  It was intended for notification but can notification be changed to just say if not status XXX by completion time then notify??
 		that way don't need to particularly indicate any status does anything
@@ -200,6 +204,10 @@ todo: workorder status first, it's a table of created items, keep properties fro
 	LockWorkorder - this status is considered read only and the workorder is locked
 		Just a read only thing, can just change status to "unlock" it
 
+todo: workorder Status table joined to Workorder
+	Has fields for statusid, workorderid, timestamp, userid
+	Write only, always just adds to the table
+
 todo: workorder notifications remove #30 and #32 as redundant
 	 WorkorderStatusChange = 4,//* Workorder object, any *change* of status including from no status (new) to a specific conditional status ID value
 	 WorkorderFinishStatusOverdue = 15,//* Workorder object not set to a "Finished" flagged workorder status type in selected time span from creation of workorderWorkorderSetToFinishedStatus
@@ -213,14 +221,17 @@ todo: workorder notifications remove #30 and #32 as redundant
 	//This one could be accomplished with WorkorderStatusAge, just pick a finished status and set a time frame and wala!
 	WorkorderFinishedFollowUp = 32, //* Service workorder closed status follow up again after this many TIMESPAN
 
-todo: workorder global setting of which roles can set a workorder status??
+todo: workorder global setting of which roles can change a workorder status??
+	in place of making certain status role specific? (above)
 
-todo: Workorder -> WorkorderService fields all together under workorder
+todo: Workorder -> WorkorderService now can combine tables all together under workorder
 	
 
-todo: decision / research - updating, in bits seperately, entirely at once?
+todo: CONCURRENCY decision / research - updating, in bits seperately, entirely at once? [## DECIDED, BITS MAKES MOST SENSE AND DIRTY TRACKING AT CLIENT ##]
+	Considering we are looking at a system where some users won't see or even get the data for some parts of teh workorder then it's important that they be able to just save their piece of it separately
+	So this strongly leans towards seperately saved and not entirely at all.
 	concurrency issue reduction 
-	Things that require an entire workorder graph be updated at once:
+	Things that might require an entire workorder graph be updated at once:
 		Major header changes? 
 			Customer, Contract because pricing and policies might change?
 		Anything that affects balances and totals (are there new features happening showing dollar amounts billable right on workorder?)
@@ -228,14 +239,25 @@ todo: decision / research - updating, in bits seperately, entirely at once?
 			in v8 some talk of seeing totals, so need to determine if that's still a thing, if not then this whole class of concurrency issues dissappears
 			This would be entirely resolved with a "view" showing a type of "invoice" summary kind of thing where you open that tab and it fetches and calcs and displays
 			however this would be little difference from a report and a little worse because the end user can't edit it to calculate how they would like it to so...
-		Notification affecting changes??
-			status?	
+
+	Dirty tracking at every level and object would save having to send entire workorder, just dirty bits
+		i.e. have non-mapped dirty fields for every woitemrecord
+		client uses them to track changes and what needs to be saved
+		upon save client goes through graph looking for dirty records and saves them each but is senstive to the best order to do it and takes into account if save would lock or unlock
+			Header fields - dirty 
+				a woitem - dirty?
+					awoitemlabor - dirty?
+		If something is changed that affects entire graph then that can be checked for at the client and trigger a full save regardless
+		WorkorderStatus change would always be the first thing saved as it might be required to UNLOCK the workorder
+		Client needs entire status list cached on hand to know if a status change affects lock status and if it's going from unlocked to locked then it would need to save the entire workorder graph and let the server handle it
+			or save bottom up before locking with the status / header change
+			Actually isn't this just handled at the server as a biz rule?  (no because if header saved first then it's locked potentially and sub items can't be save subsequently in a graph walking save)
+		New items are always dirty so a new labor record added would be dirty and saved individually
+	 	At the server upon item being saved there would always need to be a quick check of the entire workorder to see if it's LOCKED status or not
+		 	if locked then bumps back with error that wo is now locked (of course they could just change teh status in the header and resave I guess)
 			
 	
 
-todo b4 starting workorder list:
-	WorkorderStatus (check cases, very many supposedly, but they are likely more about the workorder and notification than about the status itself)
-	
 
 	------------------------------------------