diff --git a/ayanova/devdocs/todo.txt b/ayanova/devdocs/todo.txt index 25cddb9e..073ea02d 100644 --- a/ayanova/devdocs/todo.txt +++ b/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)