We have moved to GitHub Issues
Created by Shannon Deminick 18 Jul 2017, 04:49:07 Updated by Shannon Deminick 01 Aug 2017, 07:51:57
Subtask of: U4-8632
When updating the user avatar from an invite, or changing the current one in the back office the top left avatar should be updated, currently you need to log out and back in again.
In c# we can output a response header if the user information changes, then in angular we can detect this header with our http interceptor and refresh the user information
This appends a custom response header anytime the current user's data changes, the js detects this and emits an app.refreshUser event, the main controller listens to this and refreshes the user data from the server and everything is refreshed in the UI.
Ouch - ending in weird infinite loops - trying to figure it out
What happens is: user has no direct start nodes but gets start nodes from groups - CheckIfUserTicketDataIsStaleAttribute.CheckStaleData compares user's calculated content start nodes (which contains some nodes) with identity.StartContentNode (which is empty) => fails
But, BackOfficeClaimsIdentityFactory.CreateAsync assigns StartContentNodes = user.StartContentIds ie does not calculate the start nodes based on the groups.
So, we report that the user has changed, then the identity is refreshed, but groups still don't match (and never will), and we end up in an infinite loop of GetCurrentUser which kills the site.
Have changed StartContentNodes = user.StartContentIds to = user.AllStartContentIds in BackOfficeClaimsIdentityFactory -- but not sure whether we should also do it in other places?
Then, looked at BackOfficeIdentityUser.AllStartContentIds implementation: turns out it does not "calculate" start nodes but just concatenate things -- fixed by making sure we calculate -- but not sure we should also fix in other places?
So... have pushed two commits to the PR - and with this, I can change my avatar and see it change and not enter an infinite loop. However, if changing the avatar of a different user... infinite loop again - looking into it.
Silly issue, fixed, now it all works. For another user, they won't see the change until they refresh (F5) the page but I guess that's OK.
So, re-opening the issue so you can check my questions above (any other places where the same problem should be fixed), but it's working now.
Hrm, yes but this is all now different in http://issues.umbraco.org/issue/U4-10138 and I don't think we want to do this this way. We don't want the model to have to rely on any singleton or to do it's own lookups, this would be part of the model mapper to map these correctly.
I'm going to revert these commits, merge this into U4-10138 branch so everything is up to date and re-test
I've pushed the fix now. So I've merged this U4-10175 into U4-10138, have tested and is working
and merged with U4-10138
Backwards Compatible: True
Due in version: 7.7.0
Sprint: Sprint 64
Story Points: 1