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.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | user-access-hp-1212760-7.patch | 7.19 KB | balintbrews |
Comments
Comment #1
balintbrewsComment #3
balintbrewsSorry, renamed the patch file.
Comment #4
sunI think the overall concept needs a lot more discussion first, see #1200572-5: Concept of a hierarchical permission system
Comment #5
boobaa1. 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.
Comment #6
Crell commentedSubscribing. No time to review now, but I commented in the other thread.
Comment #7
balintbrewsIt 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)... sinceuser_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.
Comment #8
thedavidmeister commentedhow 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.Same thing here, no documentation at all.
+ // Backwards compatibility: if there is no delimiter, the module doesn't useThis line is over 80 characters.
Patch no longer applies.
Comment #9
andypostAnd related discussions https://groups.drupal.org/node/223189
Comment #10
catchWe'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.
Comment #24
smustgrave commentedThank 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!