This commit is contained in:
@@ -215,6 +215,11 @@ todo: cypress testing for load testing etc
|
|||||||
|
|
||||||
## SERVER MISC ITEMS
|
## SERVER MISC ITEMS
|
||||||
|
|
||||||
|
todo: notify on server boot?? (general notify to admin user or whatever?)
|
||||||
|
or on shutdown?
|
||||||
|
|
||||||
|
todo: notify on user login?
|
||||||
|
|
||||||
todo: tag based notifications need to be rechecked if tags change, not just the field(s) in question for that notification
|
todo: tag based notifications need to be rechecked if tags change, not just the field(s) in question for that notification
|
||||||
for example, user makes a workorder with closeby date and tags but tags don't match when saves
|
for example, user makes a workorder with closeby date and tags but tags don't match when saves
|
||||||
user realizes missed a critical tag, adds it and saves; notification should then check again if can apply whatever it was
|
user realizes missed a critical tag, adds it and saves; notification should then check again if can apply whatever it was
|
||||||
@@ -375,39 +380,35 @@ todo: many biz objects are not using new PUT methodology
|
|||||||
|
|
||||||
|
|
||||||
|
|
||||||
CURRENTLY DOING: notification duration display for testing workorder status age notification in app and in email
|
CURRENTLY DOING: Work order notifications
|
||||||
|
|
||||||
|
Notification related todos that came up:
|
||||||
|
Need to be able to open a wokrorder from a descendant and be taken directly to that item in the UI
|
||||||
|
scheduledonworkroder event for example will be a woitemscheduleduserid openable object
|
||||||
|
|
||||||
|
|
||||||
|
Coded, tested, done:
|
||||||
Tested:
|
WorkorderCompletedStatusOverdue
|
||||||
Overdue notification works with one user subscription
|
WorkorderStatusChange
|
||||||
Overdue notification works wiht multiple users
|
WorkorderStatusAge
|
||||||
overdue: inactive user does not receive notification
|
|
||||||
overdue: changing the close by date / time re-issues overdue notification
|
|
||||||
overdue: setting to past triggers immediate notification
|
|
||||||
Overdue: tags based works
|
|
||||||
Overdue: contract set complete by date notification works
|
|
||||||
Statuschange:
|
|
||||||
|
|
||||||
|
|
||||||
|
todo 3: workorder notifications to code and test:
|
||||||
Testing:
|
ScheduledOnWorkorder = 13,//*Workorder / WorkorderItemScheduledUser object, instant notification when current user is scheduled on a service workorder
|
||||||
|
ScheduledOnWorkorderImminent = 14,//*Workorder / WorkorderItemScheduledUser object, advanced (settable) notification when current user's scheduled date/time is imminent
|
||||||
Test with tags on each one to make sure that works as well
|
OutsideServiceOverdue = 16,//* Workorder object , WorkorderItemOutsideService created / updated, sets advance notice on due date tag filterable
|
||||||
status changed to specific status immediate notification
|
OutsideServiceReceived = 17,//* Workorder object , WorkorderItemOutsideService updated, instant notification when item received, tag filterable
|
||||||
status age, stuck in status
|
CustomerServiceImminent = 21,//* Workorder / WorkorderItemScheduledUser object?? THATS A LOT, MAYBE NO, WORKORDER SERVICE DATE OVERALL??K, notice that scheduled service is due, can set advance notice, CUSTOMER gets delivery
|
||||||
Test also as EMAIL notification as this is all also a test to find bugs in notification now rather than later
|
PartRequested = 22,//?? HOL UP, isn't this covered by objectCreated?* Workorder object / workorderitempartrequest created tag filterable
|
||||||
|
WorkorderTotalExceedsThreshold = 23,//* "the Andy" Workorder updated / created, based on balance total so conditional on DecValue
|
||||||
todo: EMAIL notification should include duration for duration events in the display
|
WorkorderCreatedForCustomer = 31, //*Service work order is created for Customer, only applies to that customer user notify sub for that customer, customer id is in conditional ID value for subscription
|
||||||
|
WorkorderCompletedFollowUp = 32, //* Service workorder closed status follow up again after this many TIMESPAN
|
||||||
|
|
||||||
todo: notify event list table needs to show status of workorder (all fields) ideally
|
todo: notify event list table needs to show status of workorder (all fields) ideally
|
||||||
otherwise if you have multiple wostatusage notifications they all appear the same
|
otherwise if you have multiple wostatusage notifications they all appear the same
|
||||||
Also it shows the email address even when it's set to in-app delivery which looks concerning and should not happen
|
Also it shows the email address even when it's set to in-app delivery which looks concerning and should not happen
|
||||||
this one might be tricky to get right, if can't then remove it entirely and just show if email or inapp delivery only not the address
|
this one might be tricky to get right, if can't then remove it entirely and just show if email or inapp delivery only not the address
|
||||||
|
|
||||||
todo 3: notification
|
|
||||||
Go through all notification types and pick out relevant ones, paste here in a list then implement one by one and test each
|
|
||||||
When that list is done, notification is done for workorder anyway
|
|
||||||
|
|
||||||
todo 3: signature: report helper display signature and form ui control to capture /display signature
|
todo 3: signature: report helper display signature and form ui control to capture /display signature
|
||||||
for both tech and customer
|
for both tech and customer
|
||||||
@@ -428,7 +429,8 @@ todo 2: open object handler for workorder descendants **VERY IMPORTANT**
|
|||||||
2) pass that on to the workorder from
|
2) pass that on to the workorder from
|
||||||
3) workorder form must open the wo in question then navigate to the descendant in question automatically
|
3) workorder form must open the wo in question then navigate to the descendant in question automatically
|
||||||
|
|
||||||
|
todo: how to directly open a workorder quickly when you know the wo number??
|
||||||
|
should be supported, otherwise you need to scroll around a list to find it which is fucked
|
||||||
|
|
||||||
|
|
||||||
todo 2-3: test and confirm can duplicate workorder and it works properly
|
todo 2-3: test and confirm can duplicate workorder and it works properly
|
||||||
|
|||||||
Reference in New Issue
Block a user