CityOfBoston / CityWorker-issues-Incapsulate

Archived for legacy purposes
0 stars 0 forks source link

Requests have non-Group owners #138

Closed jqr closed 5 years ago

jqr commented 6 years ago

See BOS311API-63.

Some Requests as seen through the Incapsulate Request API have owners which are not Groups. This violates the service contract and will cause unexpected behavior in Spot Server. Spot Server expects that owners will always be groups and ignores owners which are not Groups.

This is still happening in the latest UAT data. See Request 200983068 and ~30 more Requests.

Steps to Reproduce

  1. Load Request 200983068 in Incapsulate Request API
  2. Inspect the owner field

Expected Outcome: A Queue.

{
  "id": "00Gr00000017tWIEAY",
  "name": "PWD District 1C: Downtown",
  "type": "queue"
}

Actual Outcome: A User.

{
  "id": "005r0000001xFuKAAU",
  "name": "Swagat Talsania",
  "type": "user"
}

Impact

Assigning a Request to a User within Incapsulate probably is intended to encourage the User to look at a Request, but the net result is the Request is now practically invisible. This seems to be exactly counter to the user intentions.

vanessacalderon commented 5 years ago

Hi Elijah, yes it violates the agreement. Cases should not be assigned to Users. If that happens, it is because someone intentionally did it or the queue rule assignment failed. In this case, it looks like the queue rule assignment failed. There was an issue in UAT with the queue rule assignment failing that should have been resolved BTW. The 311 Call Center and 311 admin support should be monitoring the Cases Owned By Users report in the 311 Call Center folder to spot these cases and reallocate them back to their appropriate queue for CW users to resolve or SF users to resolve.

jqr commented 5 years ago

Awesome to hear there's already a business process in place to detect and address these.

vanessacalderon commented 5 years ago

yup, George Acker and I agreed that would be the best option for now. I think we can close this one