Recently I've shared my summary of preparing to implement hierarchical permissions, which contains the explanation of this whole approach with examples (btw I'd love to see your comments there as well as here).
Now, I'd like to show you some code. I've started the implementation with the user_access call. The algorithm has been precisely benchmarked. After that, I had to modify the checkPermissions method in the DrupalWebTestCase class to handle the hierarchical structure, because it was necessary for writing a proper test. Also needed to implement hierarchical processing in the user_permission_get_modules call with backwards compatibility layer, because we don't want to broke permissions of other modules, which don't use the new feature. Finally, my test pass, and you can see a well functioning implementation with tests.

Comments

balintbrews’s picture

StatusFileSize
new7.39 KB

Status: Needs review » Needs work

The last submitted patch, hp#1-1212760-1.patch, failed testing.

balintbrews’s picture

Status: Needs work » Needs review
StatusFileSize
new7.39 KB

Sorry, renamed the patch file.

sun’s picture

I think the overall concept needs a lot more discussion first, see #1200572-5: Concept of a hierarchical permission system

boobaa’s picture

1. Please do not mix changes regarding to only your own environment/contrib stuff with core stuff: please get rid of the first hunk that changes .gitignore.

2. while (TRUE) sounds like an infinite loop, which makes it harder to understand what the cycle does, since one has to be sure that the loop actually ends in every case by understanding every and all dark corners. Most (if not all) of the time this infinite-looking condition could be replaced by something that makes the whole cycle easier to understand.

Anyway, I'm not even sure if this kind of review is needed this early time of your coding effort.

Crell’s picture

Subscribing. No time to review now, but I commented in the other thread.

balintbrews’s picture

Title: Hierarchical Permissions #1 » user_access() for a hierarchical permission system
StatusFileSize
new7.19 KB

It has been awhile when I worked on this project, but it's time to continue. I have rerolled the patch, improved some comments in it, removed whitespaces etc. I have also changed the issue title, now it tells better, what this patch is for. Please tell me what do you think about the concept in the other issue. I will post some wireframes soon, but meanwhile, please review this patch.

@Boobaa: Thank you, I was embarassed because of the .gitignore changes, I have removed it. About the while (TRUE)... since user_access() is really important performace-wise, we (chx and me) decided to choose this way, because the benchmarks showed it a little bit faster than the other versions. So even though it's harder to read and understand, and it's not a good practice in general, it's a good trade-off I think.

@sun: I have answered in the other issue, and I'm wondering if you have further thoughts on the overall concept, or what's your opinion on this implementation.

thedavidmeister’s picture

Status: Needs review » Needs work
+  // Iterates through the parts of the permission string.
+  while (TRUE) {
+    // If the string corresponds one of the permissions, the user has the
+    // given privilege.
+    if (isset($perm[$account->uid][$string])) {
+      return TRUE;
+    }
+    // Otherwise we cut the segment after the last dot.
+    $last_delimiter = strrpos($string, '.');
+    if ($last_delimiter === FALSE) {
+      // If there are no more dots, we have to deny the access.
+      return FALSE;
+    }
+    $string = substr($string, 0, $last_delimiter);
+  }
+  return FALSE;

how do we ever get to the last return FALSE; here? the fact that it's there makes the already-confusing loop more confusing. The fact that we're doing something like while(TRUE) in core should be documented carefully, explaining why we're doing this and how we're sure that we won't end up in an infinite loop.

+      while (TRUE) {
+        if (isset($permissions[$available_permission])) {
+          unset($permissions[$available_permission]);
+          break;
+        }
+        $last_delimiter = strrpos($available_permission, '.');
+        if ($last_delimiter === FALSE) {
+          break;
+        }
+        $available_permission = substr($available_permission, 0, $last_delimiter);
+      }

Same thing here, no documentation at all.

+ // Backwards compatibility: if there is no delimiter, the module doesn't use

This line is over 80 characters.

error: core/modules/simpletest/drupal_web_test_case.php: No such file or directory
error: core/modules/user/user.test: No such file or directory

Patch no longer applies.

andypost’s picture

Version: 8.0.x-dev » 9.x-dev
Issue summary: View changes
Related issues: +#1200572: Concept of a hierarchical permission system, +#218767: Introduce sub-roles inheriting permissions
catch’s picture

Version: 9.x-dev » 8.3.x-dev
Status: Needs work » Postponed

We'd have to add this as an entirely new subsystem then gradually convert permissions and calls over to it. This means if it happens at all, it could potentially be done in 8.x. So moving back, but postponing on the ideas issue.

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

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now 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.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now 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.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now 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.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now 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.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.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.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). 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.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now 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: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

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

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

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

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

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

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now 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.

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

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now 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.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. 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 » Postponed (maintainer needs more info)
Issue tags: +stale-issue-cleanup

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.