Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

moderation: add self-action prevention #134

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

moderation: add self-action prevention #134

wants to merge 1 commit into from
+50 −12

Conversation

Samk13
Copy link
Member

@Samk13 Samk13 commented Apr 26, 2024 •
edited
Loading

❤️ 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:

Frontend

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 Samk13 added the enhancement New feature or request label Apr 26, 2024
@Samk13 Samk13 force-pushed the prevent-self-actions branch from 6d9d9d2 to da26087 Compare April 26, 2024 09:44
@Samk13 Samk13 marked this pull request as ready for review April 26, 2024 09:55
@Samk13 Samk13 force-pushed the prevent-self-actions branch 9 times, most recently from b169f51 to f113927 Compare May 3, 2024 12:38
@Samk13
Copy link
Member Author

Samk13 commented May 28, 2024 •
edited
Loading

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
Copy link
Member

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
Copy link
Member

slint commented May 29, 2024

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.

@Samk13 Samk13 force-pushed the prevent-self-actions branch from f113927 to 1c0db76 Compare May 29, 2024 17:26
@Samk13 Samk13 force-pushed the prevent-self-actions branch from 37d80fb to b166e62 Compare September 13, 2024 21:36
@Samk13
moderation: add self-action prevention
80a1149 
* 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 and approve.
* Update tests for self-action prevention
* introduce PreventSelf generator
* introduce _check_manage_permissions in users service
* add "PreventSelf" into "can_manage" permission
@Samk13 Samk13 force-pushed the prevent-self-actions branch from b166e62 to 80a1149 Compare September 13, 2024 22:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
PR Community
Status: To review ⏳
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

User Management: Admins Can Inadvertently Block Themselves Out.
3 participants
@Samk13 @zzacharo @slint