SHS:5892: Site managers can perform actions on user accounts that don't make sense with SSO

[cienvaras]

READY FOR REVIEW

Summary

• Remove "Cancel the selected user account(s)" and "Update URL Alias" bulk actions from the user list view
• In the user edit form, hide the URL alias related fields for all users and the "Cancel User" button for non admin users

Need Review By (Date)

12/04

Urgency

medium

Steps to Test

1. Log into the tugboat test site
2. Visit the People view
3. Select one or more users. Confirm one or more users and confirm that the following actions are not available anymore on the "Action" selector that appears at the bottom of the list:
   • Update URL alias
   • Cancel the selected user account(s)
4. For any user, click on the "Edit" button in the "Operations" column at the right. Confirm that:
   • There are no fields related to the URL alias visible
   • The "Cancel account" button is present at the bottom of the form
5. Masquerade as an user with the "Site Manager" role (Lindsey)
6. Repeat steps 2 through 4. Everything should be the same as for the administrator user, except that the "Cancel account" button in the user edit form shouldn't be present.

PR Checklist

• PR Checklist
• Humsci Basic PR Checklist

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1208827336999823

[cienvaras]

@joegl Before passing this to @ahughes3 I wanted a quick check on our approach. The goal of the ticket is to remove some user actions that don't make sense in a site with SSO. We removed them from the bulk operations in the user list, but also want to remove them from the user edit form. The easiest way we found is to use a form alter and set the #access to FALSE, but I wanted to check if you see any potential issue or if you consider that a different approach is better. Thanks!

[joegl]

@cienvaras The approach seems fine but a little broad. I'd like to talk H&S about this one though, because there is at least one site where Drupal accounts are created without SSO and users need to be deleted regularly. I think adding a custom permission to control this would help, and then we could still allow Administrators (those with the Developer role) to delete users.

[cienvaras]

@joegl checked with @ahughes3 and confirmed the requirements:

Only the developer role needs the ability to delete users, and no role needs to have the ability to update the URL alias of a user.

Based on this, we don't need a new permission, I just updated the form alter to check for the user roles when hiding the "Cancel account" button.

@ahughes3 This one will be ready for you to test as soon as Tugboat is working again.

[joegl]

@ahughes3 When we talked about this on Tuesday we said it should only remove the bulk cancel action and not the cancel button on the user edit form. This PR currently removes both. I just want to confirm that's what you want.

[ahughes3]

@joegl In discussing with the web team, we have removed users manually on the Women's leadership site as a support request for the unit in the past and will continue that process. We want to restrict the ability to Cancel Accounts to just the Developer role as Site Managers do not need the ability to cancel any user accounts. In testing on Tugboat it looks like as a Developer I can still Cancel an Account from the User's edit page and as a Site Manager I no longer have that ability, which meets the requirements.

[joegl]

@joegl In discussing with the web team, we have removed users manually on the Women's leadership site as a support request for the unit in the past and will continue that process. We want to restrict the ability to Cancel Accounts to just the Developer role as Site Managers do not need the ability to cancel any user accounts. In testing on Tugboat it looks like as a Developer I can still Cancel an Account from the User's edit page and as a Site Manager I no longer have that ability, which meets the requirements.

@ahughes3 Sounds good, thanks 👍 I'm ready to merge this one once you're done reviewing it 🚀

[ahughes3]

looks good!

[ahughes3]

@pookmish this PR was approved by Joe and ready to merge but was waiting for my review approval - #1682 (comment)

[pookmish]

Simple enough. An alternative would've been to create a custom permission, but that's probably unnecessary here.

[pookmish]

Oh sorry @ahughes3 , i didn't notice your comment. Let me know if we need to revert or revise it.

[ahughes3]

@pookmish it was approved by me as well, we are good to go, thank you!