ayanova/devdocs/todo.txt

@@ -189,20 +189,21 @@ todo: many biz objects are not using new PUT methodology
 CURRENTLY DOING: workorder (status), then a bit of research on api structure (see below) then get going from Client end backwards once have rough idea and flesh it out as I go along and refine
 
 todo: workorder status list 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)
+
-		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
+	SelectRoles - who can select the status (still shows if they can't select but that's the current status, like active does)	
-		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
+		This is best handled at the client.  It prefetches all the status out of the normal picklist process, more like how other things are separately handled now without a picklist
-		(can a query where clause work with a bit field? Yes: https://www.ehfeng.com/querying-bitfield-with-sql/)
-		Ok, so with being able to query on roles (theoretically), it's not actually as hard as I had originally thought, so this remains a viable thing
-		Actually, perhaps this is best handled at the client.  It prefetches all the status out of the normal picklist process, more like how other things are separately handled now without a picklist
 		client then knows if a status is available or not and can process to only present available ones
 		Server can use a biz rule to ensure that it can't be circumvented
+	
+	DeselectRoles - who can unset this status (important for process control)
+
 	FinishedStatus bool - this is a final status indicating all work on the workorder is completed, affects notification etc			
-		Do I need this?  YES, for notification of closeby missed etc
+		when set this, lock is checked in UI automatically and they need to remove it to force unlock and final
-		This should "lock" the workorder as well so no need of a lock flag for status seperately (I think, maybe consider a bit first)
+
-	??LockWorkorder - this status is considered read only and the workorder is locked
+	LockWorkorder - this status is considered read only and the workorder is locked
 		Just a read only thing, can just change status to "unlock" it
-		maybe just a finished status?  Why else lock it?? ON HOLD maybe?? but that's kind of like finished
+		to support states where no one should work on a wo for whatever reason but it's not necessarily completed		
+		e.g. "Hold for inspection", "On hold" generally etc
 
 todo: workorder Status table joined to Workorder
 	Has fields for statusid, workorderid, timestamp, userid