From 31ef6db26e57c6cef29fb33b13df4b52e893f781 Mon Sep 17 00:00:00 2001 From: John Cardinal Date: Wed, 24 Mar 2021 14:34:57 +0000 Subject: [PATCH] --- ayanova/devdocs/todo.txt | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/ayanova/devdocs/todo.txt b/ayanova/devdocs/todo.txt index 073ea02d..bd24abae 100644 --- a/ayanova/devdocs/todo.txt +++ b/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 - 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/) - 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 + + SelectRoles - who can select the status (still shows if they can't select but that's the current status, like active does) + 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 - 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 - 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 + + 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 + when set this, lock is checked in UI automatically and they need to remove it to force unlock and final + + 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