[2.x] feat(core, gdpr, nicknames)!: implement moderation abilities for user's settings

[DavideIadeluca]

Documentation PR flarum/docs#518

Fixes #0000

Changes proposed in this pull request:

• Change routing for settings route to be in line with other profile related routes
• This in turn led to implementing moderation abilities for admins to change settings / notifications / preferences and more for other users. One backend permission needed to be adjusted for that, besides this the backend stays mostly the same.

Reviewers should focus on:

• Whilst we are at it, should we in a follow up PR maybe also change the routing for the notifications (possibly more) route to be in line with this? With Notifications it's much less a user facing change (only used on mobile anyways) but from a technical perspective I think it would be good to have anyways.
• Should we set up a redirect from /settings to the users own settings page if logged in?

Screenshot

Necessity

• Has the problem that is being solved here been clearly explained?
• If applicable, have various options for solving this problem been considered?
• For core PRs, does this need to be in core, or could it be in an extension?
• Are we willing to maintain this for years / potentially forever?

Confirmed

• Frontend changes: tested on a local Flarum installation.
• Backend changes: tests are green (run composer test).
• Core developer confirmed locally this works as intended.
• Tests have been added, or are not appropriate here.

Required changes:

• Related documentation PR: (Remove if irrelevant)

[GreXXL]

Please describe in detail what settings would be available to admins. From what I understand everything. I think this could lead to admins having more easy (frontend) access to get into peoples accounts without proper logging this and therefor cause GDPR issues. This needs to be asserted carefully.

[DavideIadeluca]

Yes correct, every setting / preference and so on would avalable to Admins for every user:

So yeah Admins certainly have easier and also new permissions now to get into peoples accounts so you are right that GDPR implications need to be carefully evaluated.

I think some features should indeed be hidden / not possible for Admins to change like changing preferences for marketing type of emails or user consent like FoF Terms. Third Party extensions which add such settings / preferences need to consider this.

The other very high level part is transparency, users should be informed that changes to their accounts can be made, which can already before this PR thru the EditUserModal so from my side I think this PR doesn't really inherently change how well Flarum is GDPR compliant.

One idea in any case could be to add a little sentence in the registration flow which states this:

Administrators may access and modify account settings when required for moderation, support, security, or system operation.

[GreXXL]

I do think this needs intensive evaluation on every setting. And how would this be functionating if an extensions adds a setting? I think this is too rushed for inclusion in 2.x as it is right now.

[DavideIadeluca]

I do think this needs intensive evaluation on every setting. And how would this be functionating if an extensions adds a setting? I think this is too rushed for inclusion in 2.x as it is right now.

Extension developers should always consider GDPR implications for any feature. I feel this isn't really different here then it was previously. Extension developer extending the settings page need to evaluate on a case by case basis if a feature should be available to admins as well or just to the current user.

This PR has such an example for GDPR: The Erasure Request Flow does exactly that in that it only adds the Erasure Request Button if the app.session.user is the user in question (the backend there is already tailored to only trigger the erasure request flow for the current user)

Having said all of this... the initial idea behind this PR was to standardize the /settings routing to be in line with the user user profile routes, the moderation of other users setting was more of a side effect then the main idea so yeah from my side I'd be okay with reworking this for just the route change and hide everything else.

[GreXXL]

My thoughts:

• Enabling all settings has some major drawbacks as you can set email preferences, add tokens, etc. without propper monitoring. And even with propper monitoring I am unsure if its good to have this available to admins. GDPR Export for example should never be possible for admins as some might not want it to be sent via mail or accessable.
• It brings inconsistency which would need to be fixed at many other paces - an admin already has the option to erease an user, change mail addresses, etc. via specialized admin menus
• I think if we need settings available to be changed by admins propper admin dialoges like in GDPR with erasure, should be created

Are there usecases that triggered making setting available to admins. If so it might be interesting to learn about the usecases to find the best approach for those usecases rather then making everything available by default.