admin/raven-client
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Browse Source
This commit is contained in:
John Cardinal
2021-03-24 14:16:02 +00:00
parent 6d0ecb2304
commit 29ee7dcab5
1 changed files with 13 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
ayanova/devdocs/todo.txt
View File

@@ -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 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: 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 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 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/) (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 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 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 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?? Do I need this? YES, for notification of closeby missed etc
that way don't need to particularly indicate any status does anything This should "lock" the workorder as well so no need of a lock flag for status seperately (I think, maybe consider a bit first)
check if other cases require an endpoint "finished" status ??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 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 todo: workorder Status table joined to Workorder
Has fields for statusid, workorderid, timestamp, userid 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 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 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 WorkorderStatusAge = 24,//* Workorder object Created / Updated, conditional on exact status selected IdValue, Tags conditional, advance notice can be set
//THESE TWO ARE REDUNDANT: //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! //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 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?? todo: workorder global setting of which roles can change a workorder status??
in place of making certain status role specific? (above) in place of making certain status role specific? (above)