This commit is contained in:
2021-10-14 14:01:08 +00:00
parent d27a04cb5f
commit 80cd3dbdd8

View File

@@ -17,23 +17,28 @@
## 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))
APOLOGIZES the previous email was sent before I finished:
Have completed the migrate using 133:
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)
- 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
case 4002 - I will check after performing import that serials match, BUT see my note as there may be an issue with serials that in v7 "are not consumed" because the workorder is "open" but in v8 would and should be considered "consumed"
### 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
- see my possible suggestion.....
- 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??
## Generating HUGE dataset to confirm this and asked Joyce if this is new to this build and was not an issue before or not.
It could be the server is optimising itself based on the work load and revising it's algorithms for best query plan to run based on load and index retrieval etc??
test with huge data, note particularly if it's slow at first then speeds up as it's used
has anything change that migth add slowness aside from new version of postgres?
I have not made a case, but there is a noticeable lag when moving to different datalists..... what sort of time lag would be expected when a datalist has (for example) 10768 workorder records?
i.e. 4073 customers for the Customers datalist <- a count of 4 seconds
@@ -48,6 +53,12 @@ i.e. 10768 workorders for the Work Orders datalist <- a count of 5 seconds
Update front / back / dotnet 6 is out
https://dotnet.microsoft.com/download/dotnet/6.0
https://docs.microsoft.com/en-us/dotnet/core/compatibility/6.0
https://docs.microsoft.com/en-us/aspnet/core/migration/50-to-60?view=aspnetcore-5.0&tabs=visual-studio-code
https://gist.github.com/davidfowl/0e0372c3c1d895c3ce195ba983b1e03d
QRCoder may have issues but maybe I don't use those exact methods requiring it on linux (system.drawing.common)
https://github.com/codebude/QRCoder/issues/315
double check roles at client, the way authorizationroles.hasrole is coded makes me think it might be wrong
it only checks that the value is nonzero but in postgres I noticed it needs to compare if the resulting value equals the exact role being checked