Problem/Motivation

As #2295469: Add support for static permission definitions with *.permissions.yml removed hook_permissions from core renders

$perms = module_invoke($module, 'permission');

useless. This breaks drush https://github.com/drush-ops/drush/pull/830

Proposed resolution

Add method permissionsByModule.

Remaining tasks

Write the mock for the added test.

cd core
phpunit modules/user/tests/src/Unit/PermissionHandlerTest.php

give

1) Drupal\Tests\user\Unit\PermissionHandlerTest::testPermissionsYamlStaticAndCallback
Drupal\Core\Controller\ControllerResolverInterface::getControllerFromDefinition('Drupal\user\Tests\TestPermiss...iption') was not expected to be called more than once.

User interface changes

API changes

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Status: Needs review » Needs work

The last submitted patch, permissions-by-module.patch, failed testing.

clemens.tolboom’s picture

Issue summary: View changes
dawehner’s picture

So there seems to be indeed a usecase out there, but yeah I am not sure whether this is semantically a bug but rather a task/feature?

  1. +++ b/core/modules/user/src/PermissionHandler.php
    @@ -250,4 +250,17 @@ protected function systemRebuildModuleData() {
       }
     
    +  public function permissionsByModule($module_name)
    +  {
    ...
    +    if( $this->moduleProvidesPermissions($module_name)) {
    ...
    +    };
    ...
    +  }
    
    +++ b/core/modules/user/src/PermissionHandlerInterface.php
    @@ -54,5 +54,12 @@ public function getPermissions();
    +   *
    +   * @param $module_name
    +   * @return array
    +   */
    +  public function permissionsByModule($module_name);
     }
     
    

    Let's fix the codestyle and documentation here.

  2. +++ b/core/modules/user/tests/src/Unit/PermissionHandlerTest.php
    @@ -391,6 +391,12 @@ public function testPermissionsYamlStaticAndCallback() {
    +    foreach ($modules as $module) {
    +      $perms = $this->permissionHandler->permissionsByModule($module);
    +      $this->assertNotEmpty($perms, "Permissions for module '$module' found.");
    +    }
    

    As you expand the test coverage let's put @covers at the top.

clemens.tolboom’s picture

Issue summary: View changes
FileSize
2.22 KB

@dawehner #2 i'm not sure how to fix @covers :-(

I consider this a bug as it broke drush which has no alternative then copy the code from ::permissionsByModule()

Test needs work. How to fix this?

1) Drupal\Tests\user\Unit\PermissionHandlerTest::testPermissionsYamlStaticAndCallback
Drupal\Core\Controller\ControllerResolverInterface::getControllerFromDefinition('Drupal\user\Tests\TestPermiss...iption') was not expected to be called more than once.

Attached patch fixes #3 - #1

dawehner’s picture

Status: Needs work » Needs review
FileSize
8.45 KB
9.3 KB

There are a couple of problems:

  • Your implementation currently calls getPermissions twice (yeah implementation detail, but I think we can avoid that)
  • The tests gets more ugly and ugly over time, let's prevent that directly

There we go.

damiankloip’s picture

  1. +++ b/core/modules/user/src/PermissionHandler.php
    @@ -98,16 +98,7 @@ public function getPermissions() {
    +    return (bool) $this->permissionsByModule($module_name);
    

    Do you think !empty() would be more self descriptive here?

  2. +++ b/core/modules/user/src/PermissionHandler.php
    @@ -250,4 +241,21 @@ protected function systemRebuildModuleData() {
    +  public function permissionsByModule($module_name) {
    ...
    +    foreach ($permissions as $permission_name => $permission) {
    +      if ($permission['provider'] == $module_name) {
    

    We have a mixture between module and provider here. Do you think we should convert everything to provider? That seems to be the direction we are heading in?

  3. +++ b/core/modules/user/src/PermissionHandlerInterface.php
    @@ -54,5 +54,16 @@ public function getPermissions();
    +   * Provide list of permissions for given module.
    

    Provides

  4. +++ b/core/modules/user/src/PermissionHandlerInterface.php
    @@ -54,5 +54,16 @@ public function getPermissions();
    +   *   An array of permissions, see getPermissions() for possible values.
    

    Should we just use an @see there?

  5. +++ b/core/modules/user/tests/src/Unit/PermissionHandlerTest.php
    @@ -207,6 +163,27 @@ public function testBuildPermissionsYaml() {
    +    $this->assertEquals(['access_module_a' => [
    +      'provider' => 'module_a', 'title' => 'single_description', 'description' => '',
    +    ]], $this->permissionHandler->permissionsByModule('module_a'));
    

    I don't really mind, but I would rather just see the expected in a separate variable so the assertEquals is easier to read.

  6. +++ b/core/modules/user/tests/src/Unit/PermissionHandlerTest.php
    @@ -410,6 +387,61 @@ protected function assertPermissions(array $actual_permissions) {
    +   * Setups a permission handler with static permissions.
    

    Sets up*

dawehner’s picture

We have a mixture between module and provider here. Do you think we should convert everything to provider? That seems to be the direction we are heading in?

Well yeah but should we really rename also the moduleProvidesPermissions? I think we should do a better naming in #2338469: Add support for a core.permissions.yml as well as core.routing.yml

Should we just use an @see there?

I would vote to have both, because, well the inline reference helps to understand it.

I don't really mind, but I would rather just see the expected in a separate variable so the assertEquals is easier to read.

Sure, let's do it.

damiankloip’s picture

+++ b/core/modules/user/src/PermissionHandler.php
@@ -250,4 +242,21 @@ protected function systemRebuildModuleData() {
+  public function permissionsByModule($module_name) {

This is more permissions FOR module? By would imply I get a list grouped by module..

Xano’s picture

+++ b/core/modules/user/src/PermissionHandlerInterface.php
@@ -54,5 +54,18 @@ public function getPermissions();
+   * @return array

@return array is never ever good documentation. Always specify what exactly is in the array. Is it an array of arrays? Then use @return array[].

jhedstrom’s picture

Status: Needs review » Needs work
Issue tags: +Needs reroll, +Needs issue summary update

Patch no longer applies, and the drush issue mentioned in the summary has been fixed by other means, so I'm not sure if this is still applicable.

piyuesh23’s picture

Assigned: Unassigned » piyuesh23
Issue tags: +Goa2015
piyuesh23’s picture

Assigned: piyuesh23 » Unassigned
Issue tags: -Goa2015
AjitS’s picture

Assigned: Unassigned » AjitS

Working on it.

AjitS’s picture

Assigned: AjitS » Unassigned
Status: Needs work » Needs review
Issue tags: -Needs reroll +#drupalgoa2015
FileSize
8.86 KB

Patch was not applicable. Just rerolling for now.

dawehner’s picture

Looks pretty fine

mgifford’s picture

Re-submitting the prior patch for the bots to review.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Status: Needs review » Postponed (maintainer needs more info)

Part of the new review initiative this one came up.

Wonder after 7 years if its still a valid bug report.

If so can we also get an updated issue summary.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Status: Postponed (maintainer needs more info) » Closed (outdated)

Since there has been no activity going to close for now.

If still a valid bug please reopen updating issue summary.

Thanks all!