[1229] Support can impersonate users

[asmega]

Context

• https://trello.com/c/U0VcWDUR/1229-support-improvement-impersonate-an-rb-or-school-god-user

Changes proposed in this pull request

• Third line support staff can impersonate other users excluding other support users, computacenter users and themselves
• This feature is found on the viewing a user typically from user search results
• Whilst impersonating actions should be readonly to prevent quirky audits
• Actions whilst impersonating will therefore return forbidden and prevent the action from happening
• Users can only accept their own privacy policy, this prevents impersonation from accepting someone elses privacy policy on their behalf
• Whilst impersonating, adds a notification banner near the top of the page to show they are currently impersonating someone and who that someone is
• The banner has a button to end the impersonation

Screenshots

Support viewing a user to kickoff impersonation session

Impersonating a user

Guidance to review

• Login as third line support
• Find different users to impersonate - school user, rb user, single school user vs multi school user, user that has not accepted privacy policy
• Ensure view a of the viewing user
• Should see notification banner of current impersonation
• Should not be able to perform any actions when impersonating ie make modifications eg. invite user, change who orders etc
• Stop impersonation
• Everything should return to normal
• Should not be able to impersonate yourself just incase there are any quirks
• Should not be able to impersonate another support user so there is no privilege escalation or affecting of audits
• Should not be able to impersonate a computacenter user for the same above reason

[fofr]

Is it possible to do:

You are impersonating [Full Name](/support/users/USER_ID) (email@email.com)
[Stop impersonating]

?

Although thinking about it more – the name of the organisation might be useful somewhere.

[asmega]

Oh yea sorry, totally forgot, will do now

[asmega]

I've updated, please see screenshot

[tonyheadford]

Good work, this looks a complicated problem.
Some observations, may be just down to my test data:

• If the user has seen the privacy notice but hasn't completed the welcome wizard you can't continue
• If you get a Forbidden error you're a bit stuck unless you use browser back button
• Top menu is still for support user, not sure what options the user should have (if any) but if you hit a forbidden action it's browser back button or support home and then you can't get to the user's landing page unless you stop impersonating and re-impersonate
• When I impersonated a user with 2 schools, it also displayed my support users responsible body on the 'Your organisations' landing page (not sure thats really a problem)
• I suspect we're a bit stuck when it comes to any multi-step processes that preserve state (e.g. welcome wizard, Daily Mail)

[asmega]

Good work, this looks a complicated problem.
Some observations, may be just down to my test data:

• If the user has seen the privacy notice but hasn't completed the welcome wizard you can't continue

• I did this by design. As we want the support user to experience what the user is experiencing. If the two do not align the support user can't give accurate feedback.

• If you get a Forbidden error you're a bit stuck unless you use browser back button

• I guess so. I don't think there is a mechanism to set a back link on a forbidden page

• Top menu is still for support user, not sure what options the user should have (if any) but if you hit a forbidden action it's browser back button or support home and then you can't get to the user's landing page unless you stop impersonating and re-impersonate

• yeah i found this too and just used the browser back button. not sure how else to improve it

• When I impersonated a user with 2 schools, it also displayed my support users responsible body on the 'Your organisations' landing page (not sure thats really a problem)

• it think in your case this is merely coincidental. if you found another use with more that one school and make sure they differ from your support user you should see the impersonated user's schools. this should be covered by the changes in app/controllers/schools_controller.rb

• I suspect we're a bit stuck when it comes to any multi-step processes that preserve state (e.g. welcome wizard, Daily Mail)

• so all the authorize calls i added should prevent the support user affecting the impersonated users state. they shouldn't be allowed to affect the users state and should be readonly. if they want to change state this should be done in the support namespace.
• therefore the multi-step processes step states should be preserved unless these are kept in the session and not loaded from the database