You know that permission page, with all the checkboxes? Wouldn't it be nice if you could drag a bounding box around a bunch of those checkboxes to toggle all of the selected checkboxes? Well, since you asked so nicely...
I created a script, dps.js, and a bookmarklet that will do just that!
Step 1: Drag this link to your bookmarks toolbar to create a bookmarklet:
Drupal Permissions Script
Step 2: Visit your Drupal permissions page.
Step 3: Click the bookmarklet that you created. Nothing will seem to happen.
Step 4: Then do this:

Unable to display content. Adobe Flash is required.

Another side-effect of this bookmarklet is that the column areas that surround the checkboxes become hit-targets for the checkboxes they're near. So you can miss the stupid tiny things slightly and still toggle the box.
Here's the official repo, to which you are welcome to submit patches: https://github.com/ringmaster/serverscripts
Enjoy!

There's been a good amount of action in Habari commits lately concerning permissions. The system is finally, after much too long a delay, working well enough that it's inevitable that 0.6 will appear shortly. The permission system in Habari is steeped in a great amount of unwarranted mystery, and is pretty straightforward if you clear your mind of preconceptions and start over with some basic concepts.

First, you should be familiar with the vocabulary of permissions. Habari has the obvious user which represents a user who has successfully logged in using a username and password. There is also an anonymous user that is used to represent any user that has not logged in. Users can be members of one or more groups. Typically, permission to resources is extended by Habari to groups, which make them easier to maintain, but Habari also supports assigning permissions to users. These concepts are pretty easy, but some others might sound new.

Habari uses a thing called a token in regard to permissions. Groups and users can be given different combinations of access to any token. Access is a combination of the standard CRUD permission set: create, read, update, and delete. (Actually, in Habari currently these accesses are named create, read, edit, and delete.) To put these terms together in a sentence, a group (or user) can be assigned read and update permissions to a token. Habari also allows you to assign deny access to a token. Deny access overrides any granted CRUD permissions to a token you might have.

What are these tokens good for? Good question.

One or more tokens can be assigned to any post or action. So if you have a post that is assigned the token "artichoke", and your user (or a group your user is a member of) has "read" access to the "artichoke" token, then you are able to read that post. Likewise, if you have "edit" permission on the "artichoke" token, you may edit that post.

There are some tokens that are applied to posts in general. For example, the "post_entry" token is implicit on any post of type "entry". If your user has "read" access to "post_entry", then you can read entry-type posts. In fact, the Anonymous group, of which the anonymous user is a member, has this permission, which is why anonymous visitors to Habari sites can see the posts. If this permission is revoked, then anonymous users see nothing, and you must be logged in as a user with appropriate permissions to read any posts.

Token can also be applied to actions within the system. So a token "manage_comments" might control your user's ability to manage comments. The CRUD access rights don't apply to these tokens. Any access right on the "manage_comments" token would allow you to manage comments. Only if you have no access or have been explicitly denied access to the "manage_comments" token would you be unable to manage posts. These types of tokens are called "binary tokens" versus the "CRUD tokens" that apply to posts. Some upcoming schema changes in the Habari database will delineate these more clearly for the purpose of displaying them more effectively in the admin.

The beauty of the system is that permissions are queried with every request for posts by default, and no additional permissions checking or filtering is required. A single query returns the posts that are available for a specified user, allowing the system to operate both efficiently and effectively.

This system may seem more complex than what one would expect, and under the hood it's not trivial, but it provides an unprecedented level of permission configuration that is managed by the core software, and an API that is easy for plugins to manipulate. With this permission system it is possible to create simple private post functionality, a multi-tier subscription model, and even custom permissions to existing or brand new features within the admin.

For people that run single-user blogs, the permission system stays nicely tucked out of the way until such time as the site needs it. Guest posting anyone?