This commit is contained in:
2021-05-13 22:32:04 +00:00
parent 9730e8e96e
commit 01d8ac7f06

View File

@@ -308,42 +308,28 @@ todo: many biz objects are not using new PUT methodology
CURRENTLY DOING: labors (but involves contract change below)
Header POST doesn't need special contract handling, only put and grandchild POST / PUTS
labor, parts, travel
todo: on put needs to return object if prices updated, not just concurrency token!!
prices are *always* updated contract or not bc set by choice of part, not at client
any object modified at server must return object
only some won't need this
Contract control is working now, but haven't added code at server to update all objects when contract is changed
So, that must be done next, then can test and confirm it's working
ideally put that code in for all affected stuff now at back end rather than waiting.
NOTE: the backend contract stuff is very inadequate, it needs to also handle tagged specific values as well
todo: complete the backend contract stuff: it needs to also handle tagged specific values as well
currently it's only coded to handle the "All items" bits, not the tagged items bits so that needs to be there as well
Also it has none of the code for handling response time etc which needs to be added so take a good look and at least note the
future stuff if not appropriate right now, but it all needs to be done eventually.
NOTE: make a separate route for this, don't use the regular save route to avoid a lot of overhead
perhaps? Or maybe not, pros and cons to both
todo: contract change dialog add bit to navigate back to it again freshly
Also forgot to add bit to navigate back to it again freshly
todo: contract changes *SEE ABOVE*
update woform to show contractviz as static text with change button beside it
when you click on change, if the record is dirty it prompts to save first before proceeding
otherwise it pops up a dialog to select a new contract then immediately saves it
On success it will force a navigate to the same record to cleanly update.
Also this way people know it's a big deal to do it and it could also be wrapped in role restrictions easier too!!
At server, if NEW record and contractid already set then use that otherwise find effective one and set (only way it's set automatically) or leave empty
so user can select on new themselves
At server if UPDATE record and contract id has changed then recalc
todo: At server, if NEW record and contractid already set then use that otherwise find effective one and set (only way it's set automatically)
todo: test contract changing, application on new etc and fully works with labor before getting too carried away carrying over to other things
todo: generated wo not setting prices etc due to not being set in chunks
Add check if new object has all the data then trigger the MOASS.... setlistprice I mean! ;)
todo: tax code ref integrity check should include wo or...:
todo: tax code ref integrity check should include wo or...
technically I think it should probably just remove them from wo since they are already redundantly storing it, but also it might be good to keep it 50/50 on this one
todo: tax codes, should they just be used to SET a mirror set of fields in other objects thus allowing them to be deleted etc`
currently the workorder stores the tax code id as well as all the data about it that is relevant to teh workorder, but this sets up a link between them
that is technically unnecessary. If the intention is to decouple them, this is a bit of a wasted redundancy, however it does flow like all other things cleanly and displays etc
@@ -366,15 +352,16 @@ todo: "DispatchFull" and "DispatchLimited" roles MUST be renamed to "ServiceFull
dispatch is a subset of a service manager job
Rename at both ends and all translations and docs as well.
TODO: Workorder should include contract in effect info directly on fetch so it's available to display in UI somewhere and
to use in calculations on the form for immediate feedback if necessary
TODO: test new from scratch wo regularly
TODO: Contract rates
TODO: Contract rates pick lists
variant for picklist provide bool check contract and then aytype:id pairs that might have one.
TODO: actual feature stuff once form there
OVERALL