ayanova/devdocs/todo.txt

@@ -73,7 +73,33 @@ CURRENT ITEM:
 	BIZ OBJECT STUBBING FOR EXPORT TESTING OF HUGE ATTACHMENTS AND WIKI AND ATTACHED DOCS
 
 Workorder routes
-	One workorder route for entire graph of workorder object
+	Workorder is a "heavy" object so need to be careful how this is split out
+		Avoid full transfer of wo where possible but don't avoid it when it's the best solution
+		Don't make the client do too much work, the server has a lot of stuff it can do
+		Task oriented routes are important for the wo beyond the basic crud ops there are a lot of other tasks at hand not involving moving data (i.e. set all parts closed etc)
+
+	One workorder route for entire graph of workorder object (i.e. not a woitem route or a woitempart route etc)
+	GET/id - gets the whole workorder and all descendents in a full graph
+	PUT - Put's the whole wo and all descendents in a full graph
+	DELETE - this one is different, can specify all wo or a descendent
+		is basically a request and may return broken rule error but if it works then it returns no-content
+	MISC ROUTES for exact tasks, such as closing or whatever the UI needs to do
+	When it doesn't need to return teh whole workorder it will endeavour to avoid it but not shy away from it where necessary
+	don't want the client to have to do too much work
+	Routes that won't affect the workorder as a whole don't need to return the whole workorder, maybe just the "delta" of the descendent or object in question
+		i.e. if you add a new woitem there's no need to return all teh workorder if nothing has changed, just acknowledge it and return the id for the new row
+
+
+	Has routes for delete / add descdendents, returns whole wo object after they are executed
+		- When Add or Delete descendent is called at client, the whole wo is saved first if dirty, then after it's updated a delete / add route is triggered which returns whole wo again
+			this seems like a lot but, due to business rules and automaticicty of certain ops it needs to process the whole thing at the server 
+
+		- NOTE: not a seperate route for each type, instead, a single route that takes a type and id and parent wo id and handles deletion and returning updated wo
+			- client updates entire wo locally when it gets back the wo result of the delete
+
+		- This is important because we need a way to deal with delete add descdendents as rules need to be applied and also applied to header / totals etc
+		- e.g. workorderitem, in v7 you called delete on the woitems collection which in turn marked a woitem for deletion, but only the db update actually deleted it
+		- since v8 is disconnected need a route to do that so call delete on an item 
 	still split in db just using proper linking and stuff to work
 	start with wo->woitem and move outwards from there as that structure is basically all that's required to do the rest once figured out
 	workorder descendant types are still their own biz objects because of searching and in some cases attachments too.