moderation: add self-action prevention

[Samk13]

❤️ Thank you for your contribution!

Description

• The problem is that an admin could block his own account. With this change, it is possible to prevent the admin from doing that.
• Prevent self-action for: block, deactivate, restore, activate, impersonate and approve.
• Update tests for self-action prevention
• introduce the PreventSelf generator
• introduce _check_permission in users service
• add "PreventSelf" into can_manage and can_impersonate permission
• closes User Management: Admins Can Inadvertently Block Themselves Out. invenio-administration#203

Checklist

Ticks in all boxes and 🟢 on all GitHub actions status checks are required to merge:

• I'm aware of the code of conduct.
• I've created logical separate commits and followed the commit message format.
• I've added relevant test cases.
• I've added relevant documentation.
• I've marked translation strings.
• I've identified the copyright holder(s) and updated copyright headers for touched files (>15 lines contributions).
• I've NOT included third-party code (copy/pasted source code or new dependencies).
  • If you have added third-party code (copy/pasted or new dependencies), please reach out to an architect.

Frontend

• I've followed the CSS/JS and React guidelines.
• I've followed the web accessibility guidelines.
• I've followed the user interface guidelines.

Reminder

By using GitHub, you have already agreed to the GitHub’s Terms of Service including that:

1. You license your contribution under the same terms as the current repository’s license.
2. You agree that you have the right to license your contribution under the current repository’s license.

[Samk13]

After discussing with @slint and @zzacharo at different times, there are differing opinions on the approach:

zzach View: Suggest a UI confirmation modal instead.
slint Input: Supports using permissions to prevent these actions at the permission level.

My Position: I believe a permission-based approach is the most effective to prevent accidental self-harm actions.
A confirmation modal still risks user error (even admins are humans and they have their moments 💃🕺).

Looking forward to your thoughts to move forward.

[zzacharo]

After discussing with @slint and @zzacharo at different times, there are differing opinions on the approach:

zzach View: Suggest a UI confirmation modal instead. slint Input: Supports using permissions to prevent these actions at the permission level.

My Position: I believe a permission-based approach is the most effective to prevent accidental self-harm actions. A confirmation modal still risks user error (even admins are humans and they have their moments 💃🕺).

Looking forward to your thoughts to move forward.

I would say that if the case of preventing a self action is a core requirement then acting on permission level is necessary. That said, from the UI point of view, as also @kpsherva said in our latest call, we need to ensure that such actions are blocked in the UI and/or use a confirmation modal.

[slint]

That said, from the UI point of view, as also @kpsherva said in our latest call, we need to ensure that such actions are blocked in the UI and/or use a confirmation modal.

I think that's why we try to enforce this kind of things via permissions, since it's the closest we have to syncing backend + frontend without having to touch both. E.g. if the REST API serializes ui.permissions.can_block: false and/or links.block is missing, we can render things accordingly.

For the confirmation modals or having more user-friendly messages/popovers, it becomes difficult, since the frontend has to reason about "you can block this user, because it's you" vs. "you don't have permission to block this user".

Again, I'm not sure if the Admin UI right now supports this style, but I also feel that if we want it to, doing it via permissions is the better path.