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-05-13 22:32:04 +00:00
parent 9730e8e96e
commit 01d8ac7f06
1 changed files with 13 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files

39
ayanova/devdocs/todo.txt
View File

@@ -308,42 +308,28 @@ todo: many biz objects are not using new PUT methodology
CURRENTLY DOING: labors (but involves contract change below) 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!! 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 prices are *always* updated contract or not bc set by choice of part, not at client
any object modified at server must return object any object modified at server must return object
only some won't need this 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 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 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. 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 todo: contract change dialog add bit to navigate back to it again freshly
perhaps? Or maybe not, pros and cons to both
Also forgot to add bit to navigate back to it again freshly 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: 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: test contract changing, application on new etc and fully works with labor before getting too carried away carrying over to other things 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` 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 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 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 dispatch is a subset of a service manager job
Rename at both ends and all translations and docs as well. 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: 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. variant for picklist provide bool check contract and then aytype:id pairs that might have one.
TODO: actual feature stuff once form there
OVERALL OVERALL