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-10-14 23:58:23 +00:00
parent 7377e8ddb0
commit b7f5f4c781
1 changed files with 6 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
ayanova/devdocs/todo.txt
View File

@@ -19,18 +19,10 @@
Case 4002 still has issues
- adjustments where serials were added via v7 are now CORRECTLY accounted for in v8 yayyyy but...
- adjustments where serials were removed via v7 adjustment STILL do not appear to be accounted for in v8 (It looks like you have coded IF the serials were ADDED through a v7 adjustment, but doesn't look like coded for instances where REMOVED via a v7 Adjustment)
- serial selected in a v7 "open" workorder still showing as available serial with the Part in v8 - see my suggestion about this that the enduser themselves adjust because is
### OK, need to look at my code and see why this might be happening because I think I checked and it correctly did not migrate the serials removed via adjustment because they are not present in the availablserials list I'm using to base the serial number fixup
Case 3999
- look into consolidating unitmodel Name and Number fields into just Name and on migrate put number first then name into single name field?
Joyce suggested but for model number but name is more consistent all around
but what implications at front and back??
todo: consider putting forward / back buttons at *top* of datatables as well at least in wide view
it's annoying when the pages move the buttons up and down when you're trying to scroll quickly.
todo: make the huge generation be actually huge and let's see how far we can push it within overnight bounds of generation, i.e. set and come back next morning so should take less than 8 hours ideally
current changes to huge take 2.5 hours, want way more of every table essentially so....
@@ -799,4 +791,6 @@ BUILD 134 CHANGES OF NOTE
changed both lists to pick the "latest" workorder to be the one with the newest/highest "servicedate" field rather than by the most recently created workorder as it's possible a service date order doesn't match workorder created order
changed both lists to no longer filter the latest workorder by "Completed" status but rather just the latest service workorder (highest "Service date") regardless of status
changed translations to remove reference to "completed"
- case 4003
- case 4003
- case 3999
- case 4002 partly a fix, partly can't reproduce, see notes