Add impersonation feature for admins to webmail

[acran]

What type of PR?

Feature

What does this PR do?

This adds a button to the user list for admins to open the webmailer as another user.

Related issue(s)

• Discussion #3106

Prerequisites

Before we can consider review and merge, please make sure the following list is done and checked. If an entry in not applicable, you can check it or remove it from the list.

• [ ] ~In case of feature or enhancement: documentation updated accordingly~
• [x] Unless it's docs or a minor change: add changelog entry file.

[mergify[bot]]

Thanks for submitting this pull request. Bors-ng will now build test images. When it succeeds, we will continue to review and test your PR.

bors try

Note: if this build fails, read this.

[bors-mailu[bot]]

try

Build succeeded:

• CI-Done

[acran]

Since new elements are added to the UI (extra buttons for a user on the user list), it must be added to the documentation. webadminstration.rst.

Thank you for the suggestion. I know added the information on the new buttons to the documentation there. (I also amended the a previous commit to only show the webmail button only if webmail is actually enabled)

When using roundcube a banner is displayed in top with the information that you are impersonating an user. However this is missing for snappymaill.

Yes, I had skipped snappymail since I was unable to correctly configure it for local testing (see #3162).

Having had a look again now into snappymail, it seems to me that snappymail does not provide a straight-forward API to easily add a simple banner when logged in as another user the same way as with roundcibe. So I'm a bit skeptical whether the effort required to implement this analogously to roundcube is really worth it...

@nextgens is adding the same banner to snappymail a hard requirement for this PR? Would there be maybe another way than a banner to notify the user which may be easier to implement in snappymail?

And besides this: is there anything else blocking this PR from being merged?

[nextgens]

Can't we just frame the webmails when impersonation is in use?

[acran]

@nextgens I (rebased and) added a PoC for a framed webmail with impersonation in a8dbc5c5a1525faf850aeb00367481933bf927d3.

But in my opinion framing does not provide the best user experience and can be confusing. Because the webmailer will use the same session cookie with and without framing. So having an open tab with the admin user's normal mailbox while opening another user's mailbox with impersonation will also switch the session in the open tab to the other user's mailbox - but without the alert.

Also, having the impersonated mailbox opened in a frame (especially when keeping the mailu admin navigation as in this PoC, but that can easily be removed, though) could imply to the user that impersonation is only active in that window...

So, I'd rather let the webmailer itself handle everything instead.

But let me know which route you want to go here, and I can update the PR accordingly.

[acran]

@nextgens anything I can do to move this PR forward?

[nextgens]

bors try

[bors-mailu[bot]]

try

Build succeeded:

• CI-Done

[nextgens]

But in my opinion framing does not provide the best user experience and can be confusing. Because the webmailer will use the same session cookie with and without framing. So having an open tab with the admin user's normal mailbox while opening another user's mailbox with impersonation will also switch the session in the open tab to the other user's mailbox - but without the alert.

Also, having the impersonated mailbox opened in a frame (especially when keeping the mailu admin navigation as in this PoC, but that can easily be removed, though) could imply to the user that impersonation is only active in that window...

Those are good points; We do not want that.

Would it be doable/better to have a separate 'virtual' path for each webmail instance? So that one could open several tabs with different inboxes at the same time without having things breaking.

Say redirect to /webmail-as/[email protected]/ and have nginx proxy that too? If the path is different we may have different cookies too (so completely different parallel webmail sessions).

So, I'd rather let the webmailer itself handle everything instead.

I wanted to try out framing as that is what would be maintenance free; I am not opposed to doing it differently. If the visual indication is in the URL maybe we don't need the UX to change at all.

But let me know which route you want to go here, and I can update the PR accordingly.

As is snappymail is broken (it sets some anti-framing headers).

I'd love if you could try to make the parallel webmail session thing to work. In the future we would/could even offer all webmails by default (/webmail would redirect to either /roundcube or /snappymail)