Contrib.social

Bulk operations lists actions that the user has no access to

Open on Drupal.org →
Created on 17 July 2017, over 7 years ago
Updated 30 August 2024, 3 months ago

Problem/Motivation

Bulk operations lists all available actions for the entity without checking access to that action.

web/core/modules/system/src/Plugin/views/field/BulkForm.php:

  /**
   * {@inheritdoc}
   */
  public function init(ViewExecutable $view, DisplayPluginBase $display, array &$options = NULL) {
    parent::init($view, $display, $options);

    $entity_type = $this->getEntityType();
    // Filter the actions to only include those for this entity type.
    $this->actions = array_filter($this->actionStorage->loadMultiple(), function ($action) use ($entity_type) {
      return $action->getType() == $entity_type;
    });
  }

This appears to be because the action access is tied to access for the particular entity but not whether or not the user has access to do that type of action in general or not. ActionInterface::access() described here.

For example:

  1. Create a new role 'editor'
  2. Grant editor role 'view user information' but not 'administer users'
  3. Change /admin/people view access to 'view user information'
  4. As an editor, view /admin/people and all actions like cancel user accounts are listed as bulk action options

Proposed resolution

Creating a sample entity of the current type and passing it to the action::access() method to determine whether to show it in the bulk actions. I am not sure if creating a sample entity is a feasible approach.

Alternatively, we could provide a method like bulkAccess() on the action and allow the action to define when it is appropriate to be shown.

Or we could make the assumption that access to the confirm route means show it as a bulk action since we have this information:

@Action(
  id = "user_cancel_user_action",
  label = @Translation("Cancel the selected user accounts"),
  type = "user",
  confirm_form_route_name = "user.multiple_cancel_confirm"
)

Remaining tasks

Decide how to approach this.

User interface changes

Only show bulk action operations that the user has access to.

API changes

None (depending on route chosen to solve this).

Data model changes

None.

🐛 Bug report
Status

Active

Version

11.0 🔥

Component
Views  →

Last updated about 5 hours ago

Created by

🇬🇧United Kingdom scott_euser

Live updates comments and jobs are added and updated live.
  • Needs subsystem maintainer review

    It is used to alert the maintainer(s) of a particular core subsystem that an issue significantly impacts their subsystem, and their signoff is needed (see the governance policy draft for more information). Also, if you use this tag, make sure the issue component is set to the correct subsystem. If an issue significantly impacts more than one subsystem, use needs framework manager review instead.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment 3 months ago →
    🇨🇦Canada teknocat

    I know this issue is really old and doesn't seem to haven gotten much traction, but it really is an issue that should be resolved.

    I don't see the need for implementing the access hook in system.module, as actual access to actions is checked before running it. It's just the form that needs altering to exclude actions the user doesn't have access to from the drop-down list. It would also be prudent for the form to not display at all if no actions are available.

  • Comment 3 months ago →
    🇨🇦Canada teknocat

    Ok so I see why the access hook is needed in the system module because something needs to allow access by default. Then other modules can, when appropriate, implement the hook to forbid access when appropriate.

    Anyway, I think this is a good start to a solution but it probably needs to be more robustly implemented to be really useful. This change on it's own isn't super useful unless it can be somehow tied to the access checks for specific action plugins, or add permissions for bulk execution, or something along those lines.

    Also as per my other comment it needs to hide the form entirely from the view if there are no available actions, so there's a little extra logic needed for that as well.

    Attached is a patch to get the solution one step closer, that works against the 10.3.x branch. With this patch I can implement hook_action_access in my own custom module to apply the logic I need in my use case.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024