Drupal Permissions... taming the beast

kreynen's picture

Drupal permissions are a sticky wicket. You want to configure your site with just enough roles to make it functional and secure, but not so many roles your can't manage your permissions for Drupal's UI. But when every module, content type, as well as every field (when Content Permissions is enabled) adds an additional checkbox, this can quickly become overwhelming.

I've attached Denver Open Media's full permission configuration. I'm going post more about specific sections of this in comments to this post.

permissions_sm.jpg894.73 KB


content_permissions module

kreynen's picture

In the permission configuration interface, the content_permissions module lists every CCK field twice. Once to view and another to edit. We've tried to be consistent in our naming of fields our modules and content types giving everything an om_ prefix. If the field is used in just one module, we indicate that by including the content type in the field name. For example, field_om_show_episode_number is only used by om_show. field_om_genre is shared by om_project and om_show. field_om_genre is one of the fields that is currently set to whatever om_project is set to when new om_shows are added. We tend to set our field level permissions on Authenticated User since that applies to anyone with an account. Since the node level permissions trump field level permissions when controlling the type of content a user can create, it doesn't hurt to allow the user edit access to a field for a content type they will never be adding.


kreynen's picture

Imagecache is another module where anonymous users need to be given access.

Adding Permissions that Remove Options

kreynen's picture

There's a few places where we use permissions in a little less logical way. One is with Creative Commons licensing. I wrote a patch to add this option. Another is with MERCI's new suspend access permission. Adding these "permissions" can essentially limit permissions vs. grant them.

this is helpful

stefanwray's picture

This is helpful. I found this video about managing permissions: http://planetdrupal.tv/403
It discusses modules for permissions. Seems like some good solutions for big permission lists.

Hierarchical Permissions System

kreynen's picture

AlexUA also mentioned this Hierarchical Permissions System that several people are trying to get rolled into Drupal 7.

A quick test can save you the headache later.

PetePO's picture

I just heard about a great module that I want to get running on our sandbox site called masquerade that lets you test out the site under different permission levels without having to log in and out every time. You just pick the permission level you want to test under from a drop-down.

Every time I add a new content type etc. I always forget to test the permissions under every type of user and it always gets me in trouble later.

Once our CiviInstall is completed we're going to have about the same amount of permission groups DOM and then I absolutely know I'm going to have to use it almost every day.

The devel module suite

gollyg's picture

The devel module suite includes "Devel node access" which is very useful for checking both permissions, and the reasons that they are set the way they are. And it saves having to switch users.

MERCI Permissions

kreynen's picture

Developing a better UI for MERCI's permissions is on our list of feature requests, but it won't change how this appears in Drupal's UI (condensed or not). MERCI "borrows" space in the node table to create a placeholder reservation for the content type you are reserving. The status of the actual item you reserve isn't changed until the Reservation actually starts. Roles need edit own and delete own permission to be able to reserve items in that content type. That confuses a lot of people, but it's the best solution we could come up with.

I never got around to to

kreynen's picture

I never got around to to posting the answer to Stefan's original question that prompted this thread which was about rebuilding permissions. For some reason the interface to rebuild Drupal permissions isn't under the Permission section of the admin interface, but instead can be under admin > content > node-settings or by going directly to...


This came up again in Amherst because Workgroup Access Control was on before we started and conflicted with Organic Groups Access Control. Access Control modules are very temperamental and should be use with caution.

ClearXS's picture

Just a half year bussy to repair a site with really many modules and I must conclude that Drupal doesn't fit that job yet.

A major part of the problem is that Drupal stalls on ticking on more modules on a big module list page.

The result was yesterday (as a few times before) that near 100 (sub)modules were de-activated.

Then some settings also might be lost, as after a day work I haven't succeeded to get the articles back for anonymous users & thought I had ticked on all applying user settings so anonymous users can read the articles. Or maybe everything is unplushed again and only I as admin can see it like they are published.

Just a practical case to show that the core has a real problem processing tickign on modules and needs to be patched when something goes wrong in the internet connection or on the server, so ticked on modules are not thrown out like I have seen several times before.
I don't know where I have to file this specific issue?

Then there should be a backup list of how the moduel settings are; which ones are ticked on, with an automatic restore fascility. Actually I can't make a database backup everytime I activate one or more modules; it costs a lot of time and I have to download up to 5 times the same database, because of some strange errors, untill I have three versions that have the highest MB's (as some others have lesser). Then I have to repeat that for SQL, Text and XML.

Ofocurse a backup of user settings of those modules, too!

Any idea?

Should this be issued at certain modules whos objective comes close to this?

@ClearXSClearXS Are you

kreynen's picture

@ClearXSClearXS Are you trying to use the Open Media modules or is this a complaint about Drupal in general?

ClearXS's picture

In general; saw this info-discussion that I haven't found somewhere else..!

I'm working on 'another Open Media project' for Independent Media based on Indymedia ideas about political safe anonymous posting, no-iplog, no-email (but optional and highly secured for special features), many security modules and precautions, newswire, two editors who have to approve an article before being permanently published or unpublished in the newswire (same for putting it in the favored articles). There is IMC-Alba that works very nice in this perspective, but has some non-standard core hijacked Drupal methods of doing so. Then there is Linksunten who have changed modules like Comment-Moderation, no-mail, media-upload, but don't have a Drupal download page.
There is not a strong international project for Independent Media / Indymedia on Drupal. I don't know who finances Open Media, but that might be a problem, as there are people out there looking for ways to get in control of social media; before a proposal by the Knight Foundation was rejected for that reason. Nevertheless; developing modules (or even install profiles) that also serve Independent Media interests, would not be rejected by them, as long as they function as desired! So maybe we can coorporate a little in this perspective? (probably have to make a new topic for this, or so..)

Anyway, back to the module problems. I have 600 or more modules (to test and validate all modules that could serve), most not activated. Over the 100 modules, Drupal gets almost unworkable; fatal errors happen exponentially on the amount of modules on module update or adding one or more modules. Then resolving the problem is also exponentially more complex of the many possible interactions.

So now really modules were kicked out again on ticking on modules, because of a minor internet or server failure. A way to prevent this, would be to have a backup of the activated module list among other methods. I have that list of over 70 modules that are ready to tick for definitiev uninstall. But I cant tick them on that list for putting them back into my activated modules. I have to search everyone of them manually by working in two windows.

Trying to restore that, a fatal error happened with Content Moderation. So I had to put a dot "." in front of its module name in the sites/all/modules dir, to get drupal look over it. Actually I don't know the official way how to remove it completely from my database (so I can re-install afterwards), as I don't see it on the list of modules I can uninstall; admin/build/modules/uninstall

These types of fatal errors are going on for over half a year, reason I put important info on Mediawiki what is stable inspite of Drupal that isn't. Ofcourse I hope after selecting the better modules, filing issues and some modules that need to be integrated with new features; that I can get to a stable install profile without these high chanches on fatal errors.

P.S.: All my articles were unpublished (but as admin I could see them as published; strange). That would have been a major disaster if this was a life site with many articles. Just going to edit every article without changing anything and only hitting thwe safe button; artciles went back one by one on the front page. I'm not sure wich module is responsable for this. I have the same /content/"article-name" dir structure.

You should back up your

darrick's picture

You should back up your database before installing/uninstalling modules. If there are errors then you are using modules with bugs in them or else your php is timing out.

ClearXS's picture

It's not that easy, as I pointed out; I have to make minimal 3 backups, because my web-host sends me different sizes (so suppose some of them are corrupt), until I have minimal 3 times the same (maximum) size. Then one better does it over again for Text and XML to be sure. Then I haven't restored a database before; there is no certainty the database will be restored as original.

Then I don't have the time for it. Having 600 modules, gives 2 times a day updating for about 10 modules + sometimes more newly found modules, so 2 times database backups too in the above sketched way?

But the fix might be simple: Have a modules- and user settings-backup separate! If a tire breaks, one restores the tire, not the complete car!

(of-course something is wrong in core for that ticked on modules; I have had this too often and Drupal lacks an auto-restore when something goes wrong in the internet connection or on the server, during processing the long request)

If something goes wrong, one doesn't have to restore the complete database, but only some 'minor' settings. A module or core fix could do the work easily to have the activated modules AND the user permissions backed-up/memorized and restore them very quickly.

You all know what an awe-full lot of work it is to tick all the modules on again, or the user permissions (or the block settings, or ...)

Now I have a list of 100 (yes more than I thought) modules un-intentionally ready for ticking them to uninstall at /admin/build/modules/uninstall
But there is no field for ticking them on again, nor to tick them all on or of at the same time

For Open Media its important that it can be managed not only by highly specialized technicians, but that smaller and lesser technical groups also might be able to use Open Media; so making 'managing the beast' an easy job...

Excuse me for my chaotic initial presentation, but this is my proposal out of this chaos; core fixes, core additions and maybe additional modules (or new features to existing) to keep these settings safe and easy to restore.