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

Browse Source
This commit is contained in:
John Cardinal
2021-06-07 18:17:06 +00:00
parent 59fd41d8d0
commit 7a73e6c78e
11 changed files with 109 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
devdocs/specs/core-workorder.txt
View File

@@ -7,7 +7,7 @@ If each part has it's own concurrency then can submit whole and bits that aren't
CONCURRENCY decision / research - updating, in bits seperately, entirely at once? [## DECIDED, BITS MAKES MOST SENSE AND DIRTY TRACKING AT CLIENT ##]
Considering we are looking at a system where some users won't see or even get the data for some parts of teh workorder then it's important that they be able to just save their piece of it separately
Considering we are looking at a system where some users won't see or even get the data for some parts of the workorder then it's important that they be able to just save their piece of it separately
So this strongly leans towards seperately saved and not entirely at all.
concurrency issue reduction
Things that might require an entire workorder graph be updated at once:
@@ -38,7 +38,7 @@ CONCURRENCY decision / research - updating, in bits seperately, entirely at once
Actually isn't this just handled at the server as a biz rule? (no because if header saved first then it's locked potentially and sub items can't be save subsequently in a graph walking save)
New items are always dirty so a new labor record added would be dirty and saved individually
At the server upon item being saved there would always need to be a quick check of the entire workorder to see if it's LOCKED status or not
if locked then bumps back with error that wo is now locked (of course they could just change teh status in the header and resave I guess)
if locked then bumps back with error that wo is now locked (of course they could just change the status in the header and resave I guess)
UI stuff
@@ -47,7 +47,7 @@ UI stuff
so a single workorderitem workorder would have all fields exposed and if any grandchildren those are entered in a single form too until the user has more than one
in v7 it's three clicks to go to a grandchild items specific field from the top header, woitem click -> left nav button row selection of area click -> grid row column click
in v8 it would be one more click then if it was a multi record grandchild but if it was a single record all teh way down then all would be exposed and visible at hand could go directly to the field in question
in v8 it would be one more click then if it was a multi record grandchild but if it was a single record all the way down then all would be exposed and visible at hand could go directly to the field in question
so in this concept every level exposes an edit form below a grid of one or more items, but grid doesn't show if there is one item so it's very clean.
if there is no record at that collection then just a click to add button as unobtrusive but clearly marked as possible (if user has selected to hide that section then doesn't even show and some users don't see at all)
if multiple at that level then a grid to select the active row to edit below it showing as much data as possible in each row to help user see at a glance while editing a sibling item