I have a love/hate relationship with Node_Access in Drupal. It’s a very wonderful idea, and I’m glad we have it; it is very important to be able to create restricted content. That’s important in both a community system, where some levels of the community are behind closed doors, and it’s important in a publishing system where not all content is for all eyes, especially prior to publishing.

Unfortunately, the node_access system is very all or nothing. Multiple node access modules can’t work together. A node access module has to control every bit of content or none at all. This is especially inconvenient in systems where it’s only a small piece of the site you want to control access to, or worse—two small, unrelated pieces of the site.

Taxonomy access is currently the best way to do access control; node access by role isn’t very workable. Controlling each node independently of the others…that’s not so good, I’m afraid. But both of these are severely lacking. For taxonomy access, it’s really a pain because you have to determine how to set up access for every taxonomy term you have and it’s not too difficult to end up with odd combinations that suddenly leave half of your site inaccessible. Ideally you only want to set permissions on a given set of taxonomy.

Naturally, I have part of an idea how to fix it. Hooray for part of an idea. It’s another API. I think I solve everything with APIs, it’s in my nature. But I like for things to be able to work together.

So this one sits atop the node_access controls and provides a hook. Modules get to implement the hook, with a node, and basically asks everyone how to write the access table. Modules can respond with Yes, No and Don’t Care for each access type and for each role. Don’t Care is easy, you throw it away.The hard part here comes when one module says Yes and one module says No. Who overrides what? I’d almost consider shades of yes — “Yes” and “Yes, Dammit” where a “Yes, Dammit” overrides a no. If “Yes, Dammit” meets a “No, Dammit” we get to the immovable object versus the irresistible force, and the world ends. Or we decide up front that No is stronger than Yes. Maybe all of this is unnecessary at that point.

In any case, it then writes out the records and everyone is happy.

The downside, then, is that certain actions could trigger a need to mass-rewrite node access records. This, uh, well, kinda sucks. But changing the permissions on a taxonomy term, for instance, causes everything with that term to need a rewrite. So there needs to be a way to deal with this. I’m not sure what the best solution is offhand, but I suspect that any modules whose access methods require this would implement the query themselves, and then call the node access check functions which goes through the whole hook stuff again. I suspect this could result in a relatively long operation on large databases. Could be interesting.

Any comments? Anybody want to do it? I gots no time. =)