Experimental project

This is a sandbox project, which contains experimental code for developer use only.



Latest: I've come back to using Drupal after a long break and am now maintaining this module again.

Ever felt existing roles/permissions weren't right for controlling access to your new view? Given the choice of compromising or defining a new permission in code, you may well have compromised. I generally did.

Using this module you can quickly define new permissions through the UI. Great for controlling access to views. If you decide to refactor your roles, you won't have to edit a bunch of views whose access is controlled by role. Just add and remove the user defined permission from the relevant roles in a single step.

This module would be even more useful if Rules were to get a "User has permission" condition. I think this condition is just in the bonus pack at the moment #1338768: Condition: "User has permission" but I could be wrong.

Help: What about permission renaming? Should this be allowed? The initial ID of the permission is just its title converted to all lower case. If we allow the title to change then the ID (which might be used by a custom module) will "drift" from the the title. Changing the ID of a permission that has already been assigned to a role would be all kinds of badness.

Dependencies: This module depends on the Just in time variable project. (Also in my sandbox.) I chose to store the user-defined permissions this way because:

  1. A DB table would feel like overkill: When one user-defined permission is needed, they are all needed. (i.e. for hook_permission() and to populate the admin-screen table)
  2. Putting them in the core variable table would be wasteful: The user-defined permissions data is rarely needed and, as budda pointed out, the number of user-defined permissions could potentially be very large.

Project information