This commit is contained in:
@@ -191,25 +191,8 @@ todo: many biz objects are not using new PUT methodology
|
|||||||
|
|
||||||
|
|
||||||
CURRENTLY DOING: workorder (status) FRONT END UI (make it accessible from workorder form menu)
|
CURRENTLY DOING: workorder (status) FRONT END UI (make it accessible from workorder form menu)
|
||||||
Just got form working, looks ugly, maybe move active or fuck it????
|
|
||||||
haven't tested making new or help link yet
|
|
||||||
|
|
||||||
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: when doing wo biz need to examine every op and ensure it's up to current standards
|
||||||
|
|
||||||
todo: workorder status list first, it's a table of created items, keep properties from v7 but add the following properties:
|
|
||||||
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
|
|
||||||
UI defaults to any role
|
|
||||||
DeselectRoles - who can unset this status (important for process control)
|
|
||||||
UI defaults to any role
|
|
||||||
CompletedStatus bool - this is a final status indicating all work on the workorder is completed, affects notification etc
|
|
||||||
UI defaults to false but when set to true auto sets lockworkorder to true (but user can just unset lockworkorder)
|
|
||||||
LockWorkorder - this status is considered read only and the workorder is locked
|
|
||||||
Just a read only thing, can just change status to "unlock" it
|
|
||||||
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
|
todo: workorder Status table joined to Workorder
|
||||||
Has fields for statusid, workorderid, timestamp, userid
|
Has fields for statusid, workorderid, timestamp, userid
|
||||||
@@ -240,8 +223,7 @@ todo: workorder global setting of which roles can change a workorder status??
|
|||||||
|
|
||||||
todo: Workorder -> WorkorderService now can combine tables all together under workorder
|
todo: Workorder -> WorkorderService now can combine tables all together under workorder
|
||||||
|
|
||||||
todo: quick sanity check on how to structure a rest api for a complex object with descendant collections
|
|
||||||
just to be sure bfore I get too carried away and re-invent the wheel by accident
|
|
||||||
|
|
||||||
todo: WorkorderBiz "modernize" follow the norms of other objects
|
todo: WorkorderBiz "modernize" follow the norms of other objects
|
||||||
explicitly decouple the graph from each other, currently I think it's set to force transaction for all graph but in reality it should just be separate objects loosely coupled
|
explicitly decouple the graph from each other, currently I think it's set to force transaction for all graph but in reality it should just be separate objects loosely coupled
|
||||||
|
|||||||
@@ -202,9 +202,9 @@ export default {
|
|||||||
name: null,
|
name: null,
|
||||||
active: true,
|
active: true,
|
||||||
notes: null,
|
notes: null,
|
||||||
color: "#ffffff",
|
color: "#ffffff", //if no previously set value then control will respond with a big object with all color system values in place, this prevents that
|
||||||
selectRoles: 10,
|
selectRoles: 1290,
|
||||||
removeRoles: 10,
|
removeRoles: 1290,
|
||||||
completed: false,
|
completed: false,
|
||||||
locked: false
|
locked: false
|
||||||
},
|
},
|
||||||
|
|||||||
Reference in New Issue
Block a user