diff --git a/ayanova/devdocs/todo.txt b/ayanova/devdocs/todo.txt
index 9a4e0a04..9714210f 100644
--- a/ayanova/devdocs/todo.txt
+++ b/ayanova/devdocs/todo.txt
@@ -189,15 +189,49 @@ todo: many biz objects are not using new PUT methodology
 CURRENTLY DOING: workorder (status)
 
 todo: workorder status first, it's a table of created items, keep properties from v7 but add the following properties:
-	RolesAllowed - who can select the status (still shows if they can't select but that's the current status, like active does)
-	EndPoint bool - this is a final status indicating all work on the workorder is completed, affects notification etc
+	??RolesAllowed - who can select the status (still shows if they can't select but that's the current status, like active does)
+		But then anyone of another role can just change it to another status so this doesn't really control anything, just prevents being used by some
+		and adds hella overhead to the status picker lists / they would need post processing of some kind I think and lots of biz rules but doable
+		(can a query where clause work with a bit field? Yes: https://www.ehfeng.com/querying-bitfield-with-sql/)
+	FinishedStatus bool - this is a final status indicating all work on the workorder is completed, affects notification etc
 		Do I need this?  It was intended for notification but can notification be changed to just say if not status XXX by completion time then notify??
 		that way don't need to particularly indicate any status does anything
 		check if other cases require an endpoint "finished" status
+	LockWorkorder - this status is considered read only and the workorder is locked
+		Just a read only thing, can just change status to "unlock" it
+
+todo: workorder notifications remove #30 and #32 as redundant
+	 WorkorderStatusChange = 4,//* Workorder object, any *change* of status including from no status (new) to a specific conditional status ID value
+	 WorkorderFinishStatusOverdue = 15,//* Workorder object not set to a "Finished" flagged workorder status type in selected time span from creation of workorderWorkorderSetToFinishedStatus
+	 WorkorderStatusAge = 24,//* Workorder object  Created / Updated, conditional on exact status selected IdValue, Tags conditional, advance notice can be set
+	 
+	 //THESE TWO ARE REDUNDANT:
+	 
+	 this is actually workorderstatuschange because can just pick any status under workorderstatuschange to be notified about 
+	 WorkorderFinished = 30, //*Service work order is set to any status that is flagged as a "Finished" type of status. Customer & User
+
+	//This one could be accomplished with WorkorderStatusAge, just pick a finished status and set a time frame and wala!
+	WorkorderFinishedFollowUp = 32, //* Service workorder closed status follow up again after this many TIMESPAN
+
+todo: workorder global setting of which roles can set a workorder status??
+
+todo: Workorder -> WorkorderService fields all together under workorder
 	
 
-todo: updating, in bits seperately, entirely at once?
+todo: decision / research - updating, in bits seperately, entirely at once?
 	concurrency issue reduction 
+	Things that 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...
+		Notification affecting changes??
+			status?	
+			
+	
 
 todo b4 starting workorder list:
 	WorkorderStatus (check cases, very many supposedly, but they are likely more about the workorder and notification than about the status itself)