Closed vanessacalderon closed 4 years ago
What user account? The one associated with vanessa.calderon@boston.gov is a member of nearly every queue in the system, and would be trying to sync over 95,000 cases. As previously discussed, you'll need to test CW with a user account configured with a more typical user queue membership and workload reflecting a few hundred (or at most maybe a few thousand) cases.
Here's a list of users that are currently members of too many queues for using CW (and the related worklist size):
Belmonte, Gina | gina.belmonte@bost | 96,144
Boyd, Shanice | shanice.boyd@bosto | 96,143
Brandao, Isabella | isabella.brandao@b | 96,158
Braun, Kirsten | kirsten.braun@bost | 96,143
Brighenti, Amelia | amelia.brighenti@b | 96,143
Brohel, Michael | michael.brohel@bos | 11,414
Brookins, Makerra | makerra.brookins@b | 96,143
Brown, Derren | derren.brown@bosto | 96,143
Calderon, Vanessa | vanessa.calderon@b | 96,145
Cardarelli, Mark | mark.cardarelli@bo | 11,414
Cavanaugh, Michael | michael.cavanaugh@ | 96,155
Christopher, Allyn | allyn.christopher@ | 96,163
Cohen, Henry | henry.cohen@boston | 96,143
Coveney, Lisa | lisa.coveney@bosto | 96,143
Crowe, Justin | justin.crowe@bosto | 96,144
Daverman, Natacha | natacha.daverman@b | 96,168
Ellison, Delores | delores.ellison@bo | 96,155
Flanigan, Darcie | darcie.flanigan@bo | 96,186
Gonzalez, Tomas | tomas.gonzalez@bos | 78,070
Graham, D'Kyah | dkyah.graham@bosto | 96,154
Gregorio, Darlene | darlene.gregorio@b | 11,419
Hampel, Andrea | andrea.hampel@bost | 96,143
Hawat, Georges | georges.hawat@bost | 96,143
Heiskell, Gregory | gregory.heiskell@b | 96,155
Johnson, Aisha | aisha.johnson@bost | 96,143
Joyce, Sarah | sarah.joyce@boston | 96,156
Kennedy, Colleen | colleen.kennedy@bo | 96,143
Kotha, Ramya | ramya.kotha@boston | 96,143
Luscinski, Virginia | virginia.luscinski | 96,143
Maldonado, April | april.maldonado@bo | 11,417
Marte, Vanessa | vanessa.marte@bost | 96,143
McDonough, Francis | francis.mcdonough@ | 96,150
Mejia, Gidget | gidget.mejia@bosto | 96,143
Mitchell, Elissa | elissa.mitchell@bo | 96,143
Murphy, Maureen | maureen.murphy@bos | 96,143
Newman, Conor | conor.newman@bosto | 96,169
O'Connor, Michael | michael.p.oconnor@ | 96,184
Osgood, Chris | chris.osgood@bosto | 13,465
Palmer-Glover, Lisa | lisa.palmer@boston | 96,143
Rabb, Cerise | cerise.rabb@boston | 96,143
Ronalds-Hannon, Susana | susanna.ronalds-ha | 96,143
Samajdwar, Shatanik | shatanik.samajdwar | 96,143
Silva, Brittany | brittany.silva@bos | 96,143
Washington, Mattie | mattie.washington@ | 96,143
Ramya does not belong to any groups nor does she created cases and she cannot sync either
I think Dave that is not the issue @davemitchell
Users that belong to group All queue access. Neither Ramya nor I are included in the list
Aisha Johnson Allyn Christopher Amelia Brighenti Andrea Hampel Brittany Silva Call Center Agent Cerise Rabb Colleen Kennedy Conor Newman D'Kyah Graham Darcie Flanigan David Tran Delores Ellison Derren Brown Elissa Mitchell Francis McDonough Georges Hawat Gidget Mejia Gina Belmonte Gregory Heiskell Henry Cohen Isabella Brandao Jennifer Calderon Johnny Evans Justin Crowe Kirsten Braun Lisa Coveney Lisa Palmer-Glover Makerra Brookins Mattie Washington Maureen Murphy Michael Cavanaugh Michael O'Connor Natacha Daverman Rocco Corigliano Sarah Joyce Shanice Boyd Shatanik Samajdwar Susana Ronalds-Hannon Vanessa Marte Virginia Luscinski
here is a screenshot Dave. No queues, no groups
Also, in your list you have Chris Osgood and April Maldonado. We need to talk about you queue/group limitation to understand how we are going to resolve this. @Jailalwani
To be clear, the issue is not the number of Groups / Queues that someone belongs to, it is the total number of items to sync. At 5k+
items, the mobile client will start to perform and sync more slowly. 93k
is just too many.
While investigating this I've noticed #141 which was likely to be confusing things during testing. I've deployed a fix, resynchronized all Queues and Vanessa and Ramya now have 0 Queues assigned as expected.
Thanks Elijah, I am able to open Android. However, when I click on workgroups, the app crashes. This does not happen in Iphone. Going back to case visibility which seems to be the issue here, how are the same users in the list seeing cases in the current City Worker? According to Elissa some of the users in the list have the same case visibility as in Lagan. Maybe in the current CW they are only seeing open cases and most recent closed in CW? Maybe we could do that.....?
The list of queues for supporting a user work list is not the same as a list of all queues a user can see. This is true in CW/Lagan today as well. The work list is intended to be only queues that the user is (or could be) responsible for—that is, actually complete tasks on.
@vanessacalderon I think the Android issue should be tracked separately, would you make a GitHub Issue for it?
Cases are synced to clients under a few circumstances:
All of these are limited to open + closed recently(1 week). Older data is expunged regularly from the clients. Newer versions of Spot Mobile are expected to remove sync limits entirely, but it's not ready for public release quite yet.
I think it would be beneficial to pick a single User to inspect where we have disagreement between the systems of what data the User should have in their worklist. Pick a person and I'll make a report on which Cases they can see, and why, then we can have a discussion of that rationale.
I like that idea. I will add myself to the district group attached to the district queues and see how many cases I should see. Since I don't really understand why we migrated closed cases from 5 years ago and why CW would even want to sync that, do you want me to break it down by close/open in case we want to cap the closed cases?
I added myself to the qt3_PWD Staff District Queue Access and I can see 124 open cases (I count 125 open cases). I also count 290,445 closed or closed(transferred) cases.
ignore the project comment above. Was testing something.
Ok, I added myself to qt4_PARK Tree Staff which is a member of 4 park tree queues.
I think this is more related to an issue we had with the totals in filter not matching the total in worklist. I will find the github and relate it. When I check my worklist in CW, I have 3,332 open cases but in SF i see 3,333. Again one off or two actually since I have a PWD street cleaning SR in my work list. Now if I filter by queue/ type in CW and compare it to the number of open cases I have by queue / subject in Salesforce, I don't get the same amount. I would expect the breakdown by filter would still add up to the total in CW.... Salesforce CW Worklist CW by queue Does not add up to 3,332
CW by type does add to 3,332
Since I don't really understand why we migrated closed cases from 5 years ago and why CW would even want to sync that
I think being able to search historically for Tickets has some value, also we have a few upcoming features that are likely to make use of this.
More generally though, reasoninig about data between both systems is much easier if we can just assume that all Cases are also available in Spot Server. It certainly makes things like verifying counts easier.
Note that nearly all numbers below are not mutually exclusive. For example, you may have acccess to 2 Tickets directly and 3 through a Queue, but that could total anything from 2-5 because some of these are redundant.
Also note that what I'm describing below is data that will be synchronized to your mobile client, its not the same as worklist, although it is a superset of worklist.
Your account is in 4 Queues, all indirectly through the Group "qt4_PARK Tree Staff". And that Group is directly in each Queue and indirectly as well, through a second Group, like "qt0_PARK Tree Maintenance Request".
PARK Tree Maintenance Request
qt0_PARK Tree Maintenance Request
qt4_PARK Tree Staff
Vanessa
qt4_PARK Tree Staff
Vanessa
PARK Tree in Park
qt4_PARK Tree Staff
Vanessa
qt0_PARK Tree in Park
qt4_PARK Tree Staff
Vanessa
PARK New Tree Requests
qt4_PARK Tree Staff
Vanessa
qt0_PARK New Tree Requests
qt4_PARK Tree Staff
Vanessa
PARK Tree Emergencies
qt0_PARK Tree Emergencies
qt4_PARK Tree Staff
Vanessa
qt4_PARK Tree Staff
Vanessa
Your account will sync 3396 Tickets, 73 were directly associated with your user, and 3333 are associated through a Queue.
I'll try to do further analysis on the wordlist and filter totals you provided.
The rules for worklist are complex enough that I couldn't find a combination of removing them one by one which resulted in the count you gave. I think doing the next step from your side makes the most sense. If you can tell me the 1 Ticket that we're missing I ought to be able to dig in deeper.
Ok, I will have to dig in deeper into your matrix like email when I return from Spain. The directly associated to me puzzles me at first. Just wanted to clarify the terms so we know what we mean when we talk about group, queue, ownership or association. In SF we are relating users to a group(s) and a group(s) to queues. We have some users, aka Dave, in queues associated directly but that is not the model we should be aiming for. In SF a queue has cases and queues own cases in our model. Users view queues indirectly through group membership and do not own cases. In CW users can own tasks (a component of a case) but this is not reflected in SF nor does it cause any change in ownership of the case.
In CW users can own tasks (a component of a case) but this is not reflected in SF nor does it cause any change in ownership of the case.
This is not true, CW uses the Incapsulate PATCH Activities API to update the owner_id
when a Ticket is assigned within CW. I'm not sure if this data is visible in SF, but we definitely see it via the API.
This is not visible in SF. Whatever you do assigning tasks does not modify the ownership of the case in SF.
I still cannot understand the sync. I have access to this SF says there are 3337 cases in the 4 queues I see, which is off by 1 with the total in CW. This one seems to be the PWD Street Cleaning SR that it is CW but not in SF. However, the totals for 3/4 queues don't match. The only one that matches in PARK Tree In Park
look at PARK Tree Emergencies. When I filter by that in CW (8 cases), there are 2 cases that do not belong to that queue according to SF: 200984256 and 200984257.
as for the issue with the all queue access group, I think the decision is to have all those users go directly to V5 of CW. The workgroup in CW looks odd because it is including more users than the ones that are truly in your team handling work. For example, it will include all the call center members who do have access to all queues for visibility purposes, not for being responsible of carrying on the work resolving the case/task. I am not sure how the users will find this list useful or not seeing more people than needed if they want to assign work to their team members
I did the test of the queue count in Android.
Beware: The counts are not as simple in V4, there are quite a few filters implicitly applied. Private cases are removed from counts, closed more than 7 days, etc.
Roger that. But for that reason, I would expect that CW count would always be lower, not higher like in the three queues where there is a mismatch..... Case 200984257 in SF is in PARK Tree In Park queue, not Park Tree Emergencies and it was created on 11/20/2018, just 17 days ago.
But for that reason, I would expect that CW count would always be lower, not higher like...
Agree.
Spot Server sees Case 200984257
as being in Queue PARK Tree in Park
. This sounds like a situation where perhaps your device is out of sync with the server. I show the last change to this object was at 2018-11-20 19:28:35 UTC
.
There are no known cases where clients go out of sync like this so I'd love to hear more about your device.
Well, I have 2 phone "potatoes" like we say in Spain, meaning old stuff. I just ran the report and looked at the two phones. Numbers still higher though...
Iphone 6
Android
If those users are going to Spot 5 directly then we should probably wait for testing there. Spot 5 dramatically simplifies scoping and makes all of this much easier to verify.
@Jailalwani - agreed
I am not able to sync cases in Iphone. I can log in but nothing else happens. Trying Android but does not seem to move beyond the home screen. I do not belong to any groups. Same setting for now as Gerardo and he is able to log in.
I am not able to test.
@Jailalwani @jqr @davemitchell