Problem/Motivation
The current 7.x branch of this module is completely unusable. It just plain doesn't work. I need this module for a project, and have decided to fix it up. Note that I haven't cleaned up the existing code, and some of my new work could probably be re-factored - suggestions are welcome.
I make no garantees, but I shall attempt to fix any bugs others encounter as well.
User interface changes
In addition to the D6 functionality, I've added an additional permission: "Administer User Permissions". When a user has this, they are given access to the User Permissions tab on the user page. There, they can access this module's functionality.
Users with this can only grant permissions that they themselves already have - a user with "Administer Blocks" can give this access to other users, but not grant themselves additional access.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | small_fixes-1363246-3.patch | 3.95 KB | threewestwinds |
| #2 | small_fixes-1363246-2.patch | 4.07 KB | threewestwinds |
| port-1.patch | 9.7 KB | threewestwinds |
Comments
Comment #1
preventingchaos commentedThank you for posting this patch. I finally updated the 7.x version of the User Permissions module. I looked at your patch to help me catch up on some of the changes in Drupal 7 since I last touched this module, so part of my update is based on your patch. In the future I may add the additional functionality you put in your patch as well. Thanks again!
Comment #2
threewestwinds commentedOk, here's a simple followup. This patch fixes a few minor things (mostly code cleanup).
1) Your commit used tabs instead of spaces in places
2) Is still missing a version number from the .info file
3) Still a reference to user_admin_perm instead of user_admin_permissions in one of the comments.
Comment #3
threewestwinds commentedWoops, added one whitespace error while fixing the rest. Here's a cleaner patch.
Comment #4
threewestwinds commentedOne more thing I noticed - you do user_role_revoke_permissions($role, $old) followed by user_role_grant_permissions($role, $new).
Instead, it's better to just user user_role_change_permissions($role, $new) - it does the exact same thing as the above two lines put together. Near the comment "// Modifying existing user permissions", you can save several lines like so:
Comment #5
preventingchaos commentedGood catches! I think I have emacs setup to handle the whitespace mostly correctly now (I used this: http://drupal.org/node/59868), so tabs and extra trailing spaces shouldn't be an issue in the future.
I'll start making commits, probably targeting one thing at a time, starting with the whitespace.
Also, the 'version' number in the .info file is (supposed to be) automatically added when drupal.org creates the tar.gz/zip files, and setting it manually is actually discouraged according to this page: http://drupal.org/node/542202
Comment #6
threewestwinds commentedOh, so it is. I was pulling directly off git, so it wasn't being added. Thanks for the pointer.
Comment #7
preventingchaos commentedI fixed the whitespace (I hope) and fixed the comment.
However, after looking at the data in $form_state['input'][$rid], I found it was only giving data for the boxes that were checked in the User Permissions form. This meant that all of the array_filter() calls I was making weren't doing anything, so I removed them. It also means that there are no "false" values for user_role_change_permissions() to use for revoking permissions that were unchecked. At the moment it appears to me that the simplest way to update the permissions is to continue calling user_role_revoke_permissions() followed by user_role_grant_permissions(). But I did clean up and reorganize that bit of code in the user_permissions_profile_permissions_form_submit() function.
I pushed the commits for these changes so far.
Comment #8
threewestwinds commented