search

CityOfBoston / CityWorker-issues-Incapsulate

Archived for legacy purposes
0 stars 0 forks source link

Spot Server not syncing nested Group changes #141

Closed jqr closed 6 years ago

jqr commented 6 years ago

When making changes to a Group, the change is not propagated to other Groups that may contain the changed Group.

Example

Spot Server maps Queues to Users by recursively querying Groups until all members are Users. Imagine:

Group A
  Group A1
    User 1
  Group A2
    User 2
  User 3

In this scenario, Group A would be mapped to having members User 1, User 2, and User 3.

Steps to Reproduce

  1. Assign a User to a child Group (A1)
  2. Inspect the parent Group (A)

Expected Outcome: The parent Group (A) does contain User.

Actual Outcome: The parent Group (A) does not contain User.

Origin of Problem

The issue arises with how change detection works. When membership of the Group A1 changes, it only marks Group A1 as having changed, even though the containing Group, Group A, also changed albeit indirectly.

This was a known issue when designing the sync protocol for Groups but the fix was to consider a change for any Group to be a change to all Groups and resync all of them. This work-around was all that should be needed assuming the LastModifiedDate of a Group was always modified when membership changed.

This fix was accidentally impacted by efficiency improvements throughout the system which automatically ignore requests to resynchronize data that appear to already be fully synced. In this case the LastModifiedDate of each Group was the value returned from Salesforce. While natural, this had the unintended side-effect of appearing to be a redundant request.

jqr commented 6 years ago

The fix to this has been to override the LastModifiedDate returned from Salesforce for each individual Group and pretend it's the maximum LastModifiedDate returned from querying all Groups for changes.

This should restore the "any Group modified refreshes all Groups" feature.

I've deployed this to the UAT environment and manually refreshed all Queues. This should happen automatically going forward.

@vanessacalderon I believe the Steps to Reproduce above would be a good test to run to verify this fix from your end.