ayanova/devdocs/todo.txt

@@ -189,7 +189,7 @@ 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)
+	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/)
@@ -198,11 +198,11 @@ todo: workorder status list first, it's a table of created items, keep propertie
 		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
 	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
+		Do I need this?  YES, for notification of closeby missed etc
+		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
 		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
 
 todo: workorder Status table joined to Workorder
 	Has fields for statusid, workorderid, timestamp, userid
@@ -210,7 +210,7 @@ todo: workorder Status table joined to Workorder
 
 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:
@@ -221,6 +221,13 @@ todo: workorder notifications remove #30 and #32 as redundant
 	//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: CHANGE WorkorderFinishStatusOverdue = 15,//* Workorder object not set to a "Finished" flagged workorder status type in selected time span from creation of workorder
+	Change this to a new type that is based on so many days *without* being set to a particular status
+	but first check if tied to contract response time stuff, how that's handled 
+		that's closeby date in v7 but isn't that deprecated now without a "close"?
+		maybe I do need the Finished status bool thing above
+
+
 todo: workorder global setting of which roles can change a workorder status??
 	in place of making certain status role specific? (above)