ayanova/devdocs/todo.txt

@@ -192,85 +192,20 @@ todo: many biz objects are not using new PUT methodology
 
 CURRENTLY DOING: workorder (status) FRONT END UI (make it accessible from workorder form menu)
 
-todo: when doing wo biz need to examine every op and ensure it's up to current standards
-
-todo: workorder Status table joined to Workorder
+todo: new workorder Status table / object joined to Workorder
+	like Items collection 
 	Has fields for statusid, workorderid, timestamp, userid
 	Write only, always just adds to the table
 
-
-todo: workorder global setting of which roles can change a workorder status??
-	in place of making certain status role specific? (above)
-
 todo: Workorder -> WorkorderService now can combine tables all together under workorder
 
-
-
 todo: WorkorderBiz "modernize" follow the norms of other objects
 	explicitly decouple the graph from each other, currently I think it's set to force transaction for all graph but in reality it should just be separate objects loosely coupled
 	Fetchable as an entire graph for reporting and initial loading of UI form but updateable and fetchable separately
 	Viz stuff needs to be split out considerably to handle seperately 
 		calcing totals for entire wo
 		setting viz fields for a sub item that is saved and comes back to the client with viz fields set e.g. a workorderitemlabor record with somethign filled in from server
-	
-	ROUTES: actually, probably should code these as required rather than pre-deciding on them, let the client drive the design
-		need to handle all at once ops for entire wo as that saves traffic and it would be crazy to fetch a workorder in bits and pieces when you first open it and multiple requests when can just one trip it
-		But also need to be able to update down to a single grand child record
-		
-		Theoretical routes:
-			workorder/{wonumber}
-			workorder/{wonumber}/{woitem}
-			workorder/{wonumber}/{woitem}/{labors}
-			workorder/{wonumber}/items/parts/{WorkOrderItemPartId}
-			But, let the client drive it or it will make more work than necessary
-			if the client has what it needs then it will work for any API usage
-
-			FETCH
-				Entire wo graph
-				Sub or top part only right down to a specific grandchild record with viz fields set etc
-				I guess it's not a case of woitem and down but more a case of wo and all down or just a single item or collection of items at a single level
-			POST
-				Single item only either one of:
-				Entire wo graph
-				Descendant collection (if a collection)
-					can contain just one if that's all there is or a bunch if they were all added
-			PUT
-				Entire wo graph or 
-					descendant collections with one or more records
-			DELETE
-				same same??
-
-
-
-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 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)
-			
+				
 todo: Viz fields - calculate totals etc
 	Because of "The Andy" notification and also because it makes reporting far easier, we need viz fields to calculate all manner of totals 
 	perhaps the total calc should be split out from the regular Viz field processing to make the notification easier and less work on every save