Drupal is really great and lately I've been learning to love many of the existing modules, especially Views, CCK and a few others related to these. The power and flexibility they provide is simply amazing.

But there's one thing that I constantly bump into, which is the permissions system. Although it works perfectly for most simple cases, sometimes I need things that can't be done or are extremely complicated to get done.

And since right now I'm in the middle of one of those situations where what I want to do seems impossible, I started thinking about what I could do and I had an idea which I think is pretty interesting and with a lot of potential.

Views and CCK allow us to customize the way nodes are presented to us and what they contain. In other words, they provide us with flexibility when it comes to working with nodes.

What if we could have that same flexibility with a permissions system?

Use case

Imagine you have users on your site and you have a company node type. Via CCK, you addded a user reference field that alows you to specify which user is responsible for that company, And now you need to specify that this user will be able to edit this company. Sure, you can create a role, give that role permissions to edit own company and then you'd have to manually associate the user with that role and with the company (make the user that company's author). Sure, this would work. It would be a bit more work than I'd like to have but if it's a solution, why not? Well, how about when you need to change the user that is responsible for the company? You'll have to take the user from that special role and dissociate him/her from the company. And what about when you have some dozens of companys and hundreds of users? Seems a bit too error prone, doesn't it? And what about if you want to add a field to that company that indicates if their payments have been made on time, so that in case they're not, you can prevent the responsible user from editing it? Forget it, it's impossible, I think.

Solution

But what if you could simply edit the company, select the user you want to be respnsible for the company, and the permissions system would take care of the rest, automatically allowing that user to edit the company only if the payments were all made on time? And if you change the responsible user, no need to do anything else, the permissions system is in place taking care of it.

Proposal

For this, we would need to have a framework in place that would allow you to specify authorization rules, pretty much like Views allows you to structure queries and save them for later usage. I imagine we would have an interface that would allow us to specify a few things, divided in three columns:

  • node type
  • action to be allowed/disallowed (view/edit/delete and modules could expose their own actions to be managed by the framework)
  • and finally, the golden egg, the conditions under which the action would be allowed (like nid == xxx AND uid == x AND $node->blocked != 1)

I'm not sure if I'm explaining myself clearly but I just thought of this and I think it would be a great addition to Drupal.

This would probably have made a good SoC entry but the deadline is long gone :)

What do you guys think?

Raul

Comments

greggles’s picture

As you point out - the permission system works fine for this, but requires manual work. The goal is to automate this.

And, there is a way to do that :)

You need a site specific module that implements the hook_nodeapi and then takes actions when the "company" node type is created.

See http://api.drupal.org/api/5/function/hook_nodeapi for more details.

Perhaps some day this would be reasonable/possible with Actions, but I don't think that day is here yet...

--
Knaddison Family | mmm Free Range Burritos

borfast’s picture

I may have explained myself poorly on my first post but the examples I gave are not the only reason to create a framework like this. Another one and perhaps the biggest, is the huge mess you get when you mix several access control modules. One takes care of controling access via taxonomy, another one does it for each node individually, yet another does it considering the URL of the node...

Right now I'm ready to scrap Drupal and use another CMS for a big website I take care of, because this sh$t is driving me crazy, spending hours trying to figure out why the hell some nodes suddenly don't show up anymore in a view, just to realize that for some reason, they don't have entries in the node_access table, nor are those entries being created for new nodes. Everything was working perfectly before, when I had Taxonomy Access Control and Nodeaccess enabled. Then I disabled them and chaos is now set. It's insane!

As for my proposal, think of it as a sort of "Views" for permissions. You could build your own permissions list based on several rules (node taxonomy, node author, node ID, you name it) without needing a hundred different modules!

I thought of trying to build a prototype of this for Drupal 6 but the code freeze deadline passed and I didn't have the time to finish it but I'll still give it a try for D6 and I'll surely try to get it 100% done for D7.

Raul

EDIT: Right now, I'm fighting the damn website, trying to make it stop eating the permissions of every node I edit. Every time I edit a node, the corresponding entry in the node_access table gets deleted and consequently, no one else except for me (uid=1) can access that node!!!

borfast’s picture

Just in case anyone runs across the same problem I was having, here's how to fix it:

1 - empty the node_access table:
TRUNCATE node_access;

2 - insert one row into the node_access table with the following query:
INSERT INTO node_access(nid, gid, realm, grant_view, grant_update, grant_delete) VALUES (0, 0, 'all', 1, 0, 0);

I'm not really sure where a solution for this should be placed but it certainly needs to be taken care of, because it can kill an entire website if the admin doesn't know how to fix the problem.

Raul

borfast’s picture

Looks like my idea is being applied somewhere else :)

https://more.zites.net/workflow-ng/progress

This is exactly what I wanted to propose here, but applied to authorization/access rules. :)