devdocs/specs/core-workorder.txt

@@ -6,6 +6,35 @@ If each part has it's own concurrency then can submit whole and bits that aren't
 	test this idea
 
 
+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 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?)
+			in v7 not an issue because need to preview report to see totals
+			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...
+
+	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)
+
 
 ########### PLANNING BELOW HERE, OUTDATED NOW ########################################
 Lot's to go in here but for now this is holding my planning and thoughts until can set in stone: