devdocs/specs/core-workorder.txt

@@ -13,11 +13,16 @@ CONCURRENCY decision / research - updating, in bits seperately, entirely 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?)
 			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...
+	
+	ENTIRE GRAPH AFFECTING CHANGES
+		One idea to support this is if a change is made at header that affects all children then change their concurrency values so updates will fail 
+			This is a good idea, need a clean way to support it but this makes sense
 
 	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
@@ -36,6 +41,21 @@ CONCURRENCY decision / research - updating, in bits seperately, entirely at once
 		 	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: