This commit is contained in:
@@ -227,17 +227,19 @@ todo: many biz objects are not using new PUT methodology
|
|||||||
|
|
||||||
CURRENTLY DOING:
|
CURRENTLY DOING:
|
||||||
|
|
||||||
BIG PICTURE STUFF
|
OVERALL
|
||||||
- Duplicate test
|
- Duplicate test
|
||||||
|
- Partial save even if parts fail??
|
||||||
|
kind of the point of the new system isn't it?
|
||||||
|
or was that to allow a user to go into a specific section and edit it, not necessarily make willy nilly edits anywhere
|
||||||
- Test out role rights, login as various roles and ensure it works as expected
|
- Test out role rights, login as various roles and ensure it works as expected
|
||||||
- once pass this step then second pass at new features that affect models (not necessarily UI stuff just fields required etc)
|
- once past this step then second pass at new features **that affect models** (not necessarily UI stuff just fields required etc)
|
||||||
shouldn't be too much as already did that when recently fleshed out models but no doubt missed much
|
Add items below that are just spurious and not tied to a particular case as v.next cases YAGNI/TTM!
|
||||||
- then full in front end and flow out to back end as required, remove any backend that was a defunct evolutionary path so no cruft left around
|
- then full in front end and flow out to back end as required, remove any backend that was a defunct evolutionary path so no cruft left around
|
||||||
- Keep working on front and back responds to front needs as I go
|
- Keep working on front and back responds to front needs as I go
|
||||||
- load and stress test on client
|
- load and stress test on client
|
||||||
|
|
||||||
|
|
||||||
CURRENT ACTIONABLE TODOS
|
|
||||||
|
|
||||||
todo: status control should require click to open dialog which shows list of all status prior and allows to add then close to view
|
todo: status control should require click to open dialog which shows list of all status prior and allows to add then close to view
|
||||||
this way it's clear how to change, less confusing than now and easy to get at the list
|
this way it's clear how to change, less confusing than now and easy to get at the list
|
||||||
@@ -247,47 +249,13 @@ todo: can I turn control labels into hyperlinks for getting to feeder records?
|
|||||||
e.g. can projects title be turned to a hyper link to projects list
|
e.g. can projects title be turned to a hyper link to projects list
|
||||||
ideally not in menu because it would be a lot on a workorder and need space for wo graph subitem links
|
ideally not in menu because it would be a lot on a workorder and need space for wo graph subitem links
|
||||||
### I ALREADY have an affordance for this with the pick lists, JUST replicate that!!
|
### I ALREADY have an affordance for this with the pick lists, JUST replicate that!!
|
||||||
|
todo: Translations stuff
|
||||||
todo: failed saved on a grandchild item shouldn't preclude the rest saving
|
- "delete selected item" text instead of "Delete" for subitems
|
||||||
e.g. if there is a concurrency error on a child that shouldn't block the rest but a fatal error probably should
|
- workordercustomX translation keys not set yet, just copy workorderItem ones I guess
|
||||||
v.next? needs planning, some things should fail the whole op maybe
|
- clean up translation text, many things are badly worded for wo like all *List could just use plural form and be shorter
|
||||||
todo: do we need a dirty indicator at every level??
|
|
||||||
todo: "delete selected item" text instead of "Delete" for subitems
|
|
||||||
todo: workordercustomX translation keys not set yet, just copy workorderItem ones I guess
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
todo: clean up translation text, many things are badly worded for wo like all *List could just use plural form and be shorter
|
|
||||||
as coding it look for areas to be cleaned up
|
as coding it look for areas to be cleaned up
|
||||||
|
|
||||||
todo: how far to extend down tags, custom fields , wiki
|
|
||||||
because technically could do that easily, each child/grandchild will have own popup edit form to place those controls
|
|
||||||
would open shit up drastically for people to play around and add whatever fucking insane thing they want to each level
|
|
||||||
would certainly make Scott happy, he could put his inspection shit right in there maybe or class or whatever the fuck
|
|
||||||
Tags at the very least would make a lot of sense
|
|
||||||
wiki might be pushing it
|
|
||||||
attachments would be kind of interesting but hmm...
|
|
||||||
Custom fields also probably very useful
|
|
||||||
People would likely want some of this to display on the list format outside
|
|
||||||
Would definitely want it turned off by default, i.e. no custom fields showing
|
|
||||||
Main thing is to be able to print the custom fields and tags which is there by default now
|
|
||||||
Cons: huge form, maybe too much on it??
|
|
||||||
Just doing units for now, will consider others later
|
|
||||||
## See how units turn out in UI and go from there ##
|
|
||||||
|
|
||||||
todo: in UI the workorder state should show current state but be expandable to view list of all state changes
|
|
||||||
Most of time will want to only see the current state, not all state history
|
|
||||||
LastStateViz??
|
|
||||||
Also, this will be best for sites that don't really use the state fully and just want to ignore it or set it once to completed, that kind of thing
|
|
||||||
so maybe it's a single / collection depending on if there are more than one but collapsable??
|
|
||||||
Status control, displays last status as a read only text field maybe decorated in an H3 tag or something, but when you click on it opens a form to append a new status
|
|
||||||
control handles the rights and roles and shit
|
|
||||||
|
|
||||||
todo: remember, some users should not even have data sent from the server / scrubbed and not affect updating.
|
|
||||||
for example a user may not be able to see part costs so that should not even be sent over the wire
|
|
||||||
workorder will have to handle that as necessary adn expect sometimes data is not forthcoming
|
|
||||||
|
|
||||||
todo: UI wo descendants data table exposure (old v7 wo tree nav pane ui)
|
todo: UI wo descendants data table exposure (old v7 wo tree nav pane ui)
|
||||||
people probably want them / it's an easy way to see certain things you can't see any other way
|
people probably want them / it's an easy way to see certain things you can't see any other way
|
||||||
@@ -298,28 +266,28 @@ todo: UI wo descendants data table exposure (old v7 wo tree nav pane ui)
|
|||||||
at items level you can select any grandhild level and see a datalist for that level
|
at items level you can select any grandhild level and see a datalist for that level
|
||||||
but only top level exposed in navigation pane menu
|
but only top level exposed in navigation pane menu
|
||||||
|
|
||||||
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
|
|
||||||
Viz stuff needs to be split out considerably to handle seperately
|
|
||||||
calcing totals for entire wo
|
|
||||||
setting viz fields for a sub item that is saved and comes back to the client with viz fields set e.g. a workorderitemlabor record with somethign filled in from server
|
|
||||||
|
|
||||||
todo: Viz fields - calculate totals etc
|
todo: Should workorderitemloan be included in contract discounting system??[v.Next?]
|
||||||
This is a bit fucky becuase it means every item added needs to update the entire workorder even though they are decoupled
|
|
||||||
maybe an on demand recalc total or it separately does it at the back end and just provides an update or...???
|
|
||||||
But because of notification issues we do need to know it on every update (the andy)
|
|
||||||
if this is the only reason then the andy needs a re-think, no one has asked for it but one site and it would affect a lot of shit
|
|
||||||
Because of "The Andy" notification and also because it makes reporting far easier, we need viz fields to calculate all manner of totals
|
|
||||||
perhaps the total calc should be split out from the regular Viz field processing to make the notification easier and less work on every save
|
|
||||||
or maybe even a separate function to calc the only number needed for the Andy and leave the Viz to be as it is
|
|
||||||
(though there is probably so much overlap and same work required that in fact it's more sensible to have a split viz set fields for totals seperately)
|
|
||||||
|
|
||||||
todo: Should workorderitemloan be included in contract discounting system??
|
|
||||||
i.e. should *anything* that can be charged for on a workorder and which you don't directly enter a price (like outside service) be part of contracting system??
|
i.e. should *anything* that can be charged for on a workorder and which you don't directly enter a price (like outside service) be part of contracting system??
|
||||||
|
|
||||||
todo: - Skip links when it gets big ??:
|
todo: how far to extend down tags, custom fields , wiki [v.Next?]
|
||||||
https://www.voorhoede.nl/en/blog/why-skip-links-are-important-for-accessibility/
|
## UNLESS A FEATURE REQUIRES IT....MAYBE WAIT FOR FEEDBACK / IMPLEMENT LATER
|
||||||
|
because technically could do that easily, each child/grandchild will have own popup edit form to place those controls
|
||||||
|
would open shit up drastically for people to play around and add whatever fucking insane thing they want to each level
|
||||||
|
would certainly make Scott happy, he could put his inspection shit right in there maybe or class or whatever the fuck
|
||||||
|
Tags at the very least would make a lot of sense
|
||||||
|
really??
|
||||||
|
wiki might be pushing it
|
||||||
|
definitely
|
||||||
|
attachments would be kind of interesting but hmm...
|
||||||
|
Custom fields also probably very useful
|
||||||
|
People would likely want some of this to display on the list format outside
|
||||||
|
Would definitely want it turned off by default, i.e. no custom fields showing
|
||||||
|
Main thing is to be able to print the custom fields and tags which is there by default now
|
||||||
|
Cons: huge form, maybe too much on it??
|
||||||
|
Just doing units for now, will consider others later
|
||||||
|
## See how units turn out in UI and go from there ##
|
||||||
|
|
||||||
|
|
||||||
------------------------------------------
|
------------------------------------------
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user