This commit is contained in:
@@ -88,7 +88,25 @@ todo: PLANNING workorder data and class and route structure:
|
||||
likely follows biz object decision
|
||||
Use foreign keys!!
|
||||
Consider UI in this as well, will need to decide at least what is visible when
|
||||
How to add items, like new woitem?
|
||||
send to server get back new object?
|
||||
lots of biz rules and stuff need to happen, want to minimize load at client
|
||||
but lots of data back and forth is not ideal
|
||||
maybe request a woitem and get it back?
|
||||
what exactly needs to be processed in the wo when items are added / removed?
|
||||
math / totalling?
|
||||
simple calcs sb client doable
|
||||
this will drive what has to happen.
|
||||
Need to go over all wo features and factor them into this decision properly
|
||||
The whole idea of a completed section of a wo and stuff, is that dropped due to TTM or still viable?
|
||||
maybe can pick out the best new features of that which can be integrated into existing design rather than re-inventing the wheel
|
||||
How best to be able to service LoanUnits on a workorder?
|
||||
Just make them Units with extra properties exposed if type of loaner?
|
||||
This seems simplest, but what will it effect?
|
||||
Hard to make them serviceable if they are an alternate table of source for what's being repaired as that breaks a lot of other code or adds exceptions
|
||||
|
||||
|
||||
|
||||
|
||||
---------------------------------------------
|
||||
|
||||
@@ -148,6 +166,8 @@ todo: PLANNING session tracking to prevent logging in from multiple devices with
|
||||
- Perhaps we track the download token or something during certain requests to server so it can return a 403 and redirect to login if they are on another session
|
||||
- or maybe the download route should return the not authenticated response to force login again
|
||||
- maybe part of JWT session key of some kind that must be current to work to prevent multiple logins
|
||||
- JWT TOKEN for image download??
|
||||
- JWT TOKEN too large? sb as tiny as possible, currently too much info in it?
|
||||
ACTION:
|
||||
- First determine if this is a bad thing or should be supported to some degree.
|
||||
- like, maybe user is in more than one tab at the same time?
|
||||
|
||||
Reference in New Issue
Block a user