Taming the Drupal 5 Permissions System

A few weeks ago I wrote a short how-to on allowing various roles to view unpublished content without having the 'administer nodes' permission in Drupal 5. At that time I promised to write a follow-up article on taming the Drupal 5 permissions system, allowing for additional circumvention of the monolithic 'administer nodes' permission. A few weeks, and one cramped cross-country flight later, that article (and the code behind it for that matter!) has finally 'landed' as it were. The first step is once again to query the database for a list of all content types in the system, and then loop through them and output appropriately granular permissions for the various publishing options we want to support. Once we've done that we have the ability to assign these permissions on a per-role basis. However, this does nothing for making the permissions to show up on the node editing form, so we'll have to create a implementation of hook_form_alter to add the checkboxes into the node edit forms where appropriate. That's going to look like this: Now we just need to add in a submit callback to set these values on the node object, or we can write some ugly queries which set these values in the database direc... wait, what?! we don't? Nope, we don't. We're done. The beauty of this method is that the forms submit handler, node_form_submit(), will still do all the hard work for us. Node.module does it's access control for this functionality by adding a '#access' key to the 'Publishing Options' fieldset when creating a node add/edit form, meaning in form node.module originally built gets processed by the Forms API it will omit the publishing options if the current user doesn't have sufficient privileges. There's no reason for it to do a follow-up permissions check after the form is submitted, since the built in security in the Forms API will disregard any values submitted which weren't in the form after it was originally built (preventing malicious users from adding additional fields to the form). What that boils down to in less-nerdy terminology is this; if these values show up in a form after it's submitted then the fields were put there by a module, and node.module isn't concerned with whether it created the form fields, or whether they come from another module. It's interesting to compare this to the method I wrote about to allow users to view unpublished content. In both cases we're modifying access rules to functionality that core provides. With the view_unpublished module we were able to selectively override the menu items responsible for displaying nodes. With this module, we selectively override elements in the node forms to display when conditions we set are met. In both cases, the Drupal core provided a great road-map for how to properly achieve our goals, and our modifications boil down to overriding the default access checks core uses. It's a testament to the Drupal core that it's flexible enough to allow these modifications from the outside-in, without requiring developers to destroy their upgrade path to get the features they need.