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

case 4003

Browse Source
This commit is contained in:
John Cardinal
2021-10-14 22:46:47 +00:00
parent 07aea598e1
commit 9c3530bbe5
1 changed files with 6 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
ayanova/devdocs/todo.txt
View File

@@ -17,10 +17,6 @@
## ROUGH SCHEDULE TO GET TO BETA
case 4003 showing active users, probably a missing bracket in
.Where(x => x.Active == true && x.UserType == UserType.ServiceContractor || x.UserType == UserType.Service)
sb
.Where(x => x.Active == true && (x.UserType == UserType.ServiceContractor || x.UserType == UserType.Service))
Case 4002 still has issues
@@ -38,6 +34,8 @@ Case 3999
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....
todo: workorder seeding should have few if any service date in the future unless it's just a few days, the vast majority should be within the current month or maybe the next at most
security jwt tokens and expiration, can a user just keep working if they are set to inactive because their token hasn't expired?
should tokens refresh periodically and have a super short life?
https://stackoverflow.blog/2021/10/06/best-practices-for-authentication-and-authorization-for-rest-apis/?utm_source=Iterable&utm_medium=email&utm_campaign=the_overflow_newsletter
@@ -798,6 +796,7 @@ BUILD 134 CHANGES OF NOTE
- Customer and Unit data lists
Fixed performance issue with last workorder stuff
Fixed bug in Unit where it was checking the Unit against the workorderitemunit.ID field instead of the workorderitemunit.UNITID field resulting in random and completely wrong workorders (customer one was ok for this)
changed both lists to pick the "latest" workorder to be the one with the newest "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 regardless of status
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