Contrib.social

Error: Call to a member function isAllowed() on bool

Open on Drupal.org →
Created on 30 March 2022, over 2 years ago
Updated 1 February 2024, 10 months ago

Problem

When I try to use Views Bulk Operations with my custom actions to publish or unpublish content, I receive the following error:

An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: /batch?id=8076&op=do_nojs&op=do
StatusText: OK
ResponseText: Error: Call to a member function isAllowed() on bool in Drupal\views_bulk_operations\Service\ViewsBulkOperationsActionProcessor->process() (line 461 of /app/web/modules/contrib/views_bulk_operations/src/Service/ViewsBulkOperationsActionProcessor.php).

This used to work without error with v4.1.0, but after upgrading the module to v4.1.2 I get the error above.

Steps to reproduce

- Enable VBO v4.1.1+ and the content moderation module.
- Define node states such as draft, review, published, and unpublished and related workflows.
- Create a custom publish action following the documentation → with an access function like:

  public function access($object, AccountInterface $account = NULL, $return_as_object = FALSE) {
    if ($object->getEntityType() === 'node') {
      $access = $object->access('update', $account, TRUE)
        ->andIf($object->status->access('edit', $account, TRUE));
      return $return_as_object ? $access : $access->isAllowed();
    }

    // Other entity types may have different
    // access methods and properties.
    return TRUE;
  }

- Configure VBO on a content view with your custom publish action.
- Attempt to use VBO on the content view to publish an unpublished content node and note resulting error.

Proposed resolution

I believe this issue was introduced with Issue #3246212 → .

The problem is a result of the change to the ViewsBulkOperationsActionProcessor.php process() function on line 461. It now assumes that all access() functions will return an object with an isAllowed() member. However, the example access() function from the documentation has a default/fallback condition at the end of the function where it simply returns a boolean TRUE. (Resulting in the "Call to a member function isAllowed() on bool" error that I'm experiencing.)

It's unclear to me whether the best/desired fix is to ensure that our custom access() functions always return an object or modify process() such that it doesn't error if access() returns a boolean.

Remaining tasks

Additionally, I uncovered several other underlying problems with the example access() code in the documentation → . This code appears to be for an earlier version of Drupal and the entity API has since changed:

- $object->getEntityType() should be changed to $object->getEntityTypeId()
- $object->status->access('edit', $account, TRUE) should be changed to $object->access('edit', $account, TRUE)

The example code in the documentation needs to be updated to reflect these changes because right now it's not actually doing any access checks and simply defaulting to granting access.

🐛 Bug report
Status

Closed: works as designed

Version

4.1

Component

Actions

Created by

🇺🇸United States RichardDavies Portland, Oregon

Live updates comments and jobs are added and updated live.
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 10 months ago →
    🇺🇸United States rymcveigh

    Thank you for documenting this. It helped us resolve the same issue with a custom module.

  • Comment about 1 month ago →
    🇨🇴Colombia jasonac91

    None of this works, with any version after 4.1.0

  • Comment about 1 month ago →
    🇨🇴Colombia jasonac91

    This patch addresses an issue where the access() method could potentially return a boolean instead of an expected AccessResult object in the ViewsBulkOperationsActionProcessor class. This was causing a fatal error ("Call to a member function isAllowed() on bool") when attempting to call isAllowed() on what was assumed to be an AccessResult object but was actually a boolean value.

    The provided solution adds a check to ensure that the $accessResult variable is indeed an object and specifically that it possesses the isAllowed() method before attempting to call it. This check prevents the fatal error by verifying the type and method existence:

    The patch first checks if $accessResult is an object and if it has the method isAllowed using PHP's is_object() and method_exists().
    If these checks pass, it processes to verify if the access is allowed.
    If $accessResult is not an object or does not have the isAllowed() method, it logs an error stating that the access result is not a valid AccessResult object. This helps in identifying configuration or code issues that might be causing unexpected return types.
    By implementing this, we ensure the robustness of the process() function in handling cases where the action might not adhere to the expected return type conventions. This change is crucial for maintaining the stability and reliability of bulk operations within Views Bulk Operations, especially in complex environments where different actions might be configured to return non-standard access results.

    This patch is attached for review and testing. It has been tested in my local environment where the issue was replicated and verified that the patch resolves the problem without affecting the existing functionalities.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024