ayanova/devdocs/todo.txt

@@ -72,41 +72,6 @@ CURRENT TODOs
 CURRENT ITEM:
 	BIZ OBJECT STUBBING FOR EXPORT TESTING OF HUGE ATTACHMENTS AND WIKI AND ATTACHED DOCS
 
-Workorder routes
-	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.
-		- Not sure how deep to support attaching and custom fields, it's going to impact the UI a lot if I get too crazy with it, but maybe keep it as an idea
-			- Add CUSTOM FIELDS to top level as the new thing (previously only woitem in v7)?
-			- Add wiki and attachments to woITEM level (new thing, previously only header)?
-		- going to need a lot more aytypes for the full graph of each type of workorder basically or whatever it supports
 
 
 Modify v8 export to export everything (at least teh wikiable and attachable and custom fieldable)
@@ -789,8 +754,49 @@ todo: workorder UI layout stuff (TTM!!  Don't re-invent the wheel!)
 		On a PC people will want and expect it to look as much like v7 workorder as possible, maybe that's still a valid layout
 			just tweaked to work better as a web app a bit but theoretically I could almost duplicate that layout with the tools I have
 		
+WORKORDER BACKEND THOUGHTS
+=-=-=-=-
+Workorder routes
+	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)
+	Shadow properties
+		- will need shadow properties not persisted but that tell teh UI stuff like "canDelete" for a workorderitem etc
+		- this will save a lot of business rule checking at the client end
 
 		
+	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.
+		- Not sure how deep to support attaching and custom fields, it's going to impact the UI a lot if I get too crazy with it, but maybe keep it as an idea
+			- Add CUSTOM FIELDS to top level as the new thing (previously only woitem in v7)?
+			- Add wiki and attachments to woITEM level (new thing, previously only header)?
+		- going to need a lot more aytypes for the full graph of each type of workorder basically or whatever it supports
+	=-=-=-=-=-
+
 todo: Documentation
 	Need to think this through carefully
 	Need to get the critical bits in for onboarding and importing so people can get going