Probably a caching issue for impersonate feature on an admin user

[paulo-graca]

Describe the bug After a user was created, as an admin I've assign him the admin profile and went to see the user profile.

Then I assign him the admin group

Back on the user profile page I was able to see actions that I think they don't apply for users in that profile

To Reproduce Steps to reproduce the behavior (I've used Firefox on Windows 10):

1. I sign in using shibboleth authentication. Then an account was created
2. Then I sign in as an administrator and visit the user profile firstly
3. Went to groups management and assigned the new user to the administrator group
4. On the users list, I went to see the eperson profile
5. On the eperson profile (the recently group data added wasn't yet available) the impersonate option was available and I click it. No visible error occurred reload action got stuck on the loading content (the dots animation).

Expected behavior I think you couldn't impersonate another admin. If that's the case, then, the user profile should be updated with the required features and permissions/authorizations, also, it should display the recently groups added.

[tdonohue]

Thanks @paulo-graca : I can reproduce this.

It looks like a caching issue to me. The groups listing on the EPerson edit page is not reloading.

How to reproduce:

1. Edit an EPerson
2. Add them to a Group (any group)
3. Go back to that same EPerson Edit page. Their group will not be listed. However, if you reload the page (click browser's reload button), then the group will appear.

Moving this to 7.4 and flagging as high priority.

[artlowel]

This will take an estimated 4 hours Atmire would like to claim it

[artlowel]

@tdonohue While working on this issue we discovered two more related issues involving caching and the groups page:

1. if you delete the last member of a group, the members list will not update.
   • The reason is that the observableCombineLatests here and here will have no parameters if there are no members, so won't emit. This needs to be rewritten in a different way, to allow for empty result lists
2. If you've retrieved something first using its self link, then using an alternative link, and then set the self link request to stale, the original component won't switch over to the alternative link version, instead it will hang because it's observing a part of the store that will never be updated again (a stale request).
   • After the fix for this original issue was put in place, we noticed this issue when we
     • went to a group page (which will retrieve the group using its self link),
     • then added a person (which will set the group self link to stale),
     • and went to their profile page (which will retrieve the group again, this time using the link on the eperson, an alternative link)
     • and then back to the group page. That page would hang.
   • The culprit is this observableRace, because the self link request will 'win' the first time, but afterwards the race is never run again. This needs to be replaced with a more sophisticated way of comparing requests

We can fix both these issues in an additional 10 hours

[tdonohue]

@artlowel: I agree that it makes sense to just solve all these issues together. I'll bump the estimate on this ticket up to 14 hours & you can just fix these all together then.

[artlowel]

Closing. This was fixed by #1808, but not linked up to the PR properly so not closed automatically