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
2020-05-06 13:59:53 +00:00
parent 42a74cd84a
commit fbe9b797bd
1 changed files with 20 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
ayanova/devdocs/todo.txt
View File

@@ -88,7 +88,25 @@ todo: PLANNING workorder data and class and route structure:
likely follows biz object decision likely follows biz object decision
Use foreign keys!! Use foreign keys!!
Consider UI in this as well, will need to decide at least what is visible when 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 - 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 - 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 - 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: ACTION:
- First determine if this is a bad thing or should be supported to some degree. - 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? - like, maybe user is in more than one tab at the same time?