This commit is contained in:
@@ -186,7 +186,7 @@ todo: many biz objects are not using new PUT methodology
|
||||
|
||||
|
||||
|
||||
CURRENTLY DOING: workorder (status)
|
||||
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)
|
||||
@@ -225,7 +225,10 @@ todo: workorder global setting of which roles can change a workorder status??
|
||||
in place of making certain status role specific? (above)
|
||||
|
||||
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
|
||||
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
|
||||
Fetchable as an entire graph for reporting and initial loading of UI form but updateable and fetchable separately
|
||||
|
||||
Reference in New Issue
Block a user