Minutiæ

Notice: I have neither posted nor updated any content on this blog since the mid 2010's. (😱) Please check out the homepage and my bio, for more recent things. Below is the original content of this post:

I've been developing in Django for the Spokesman-Review for just over a month and a half now on our super exciting new Web site project -- we most recently got a team together to churn out a replacement for our current blog platform.

A major issue we came across was the problem of multiple blog users on the single Django installation. The permissions setup was great, but wasn't granular enough for our needs -- it was impossible to filter out the admin panel to only display blogs that a particular staffer is assigned to. At least, without having to write our own blog-specific admin panel (or writing managers that plug into the existing Django admin panel -- yuck!).

Anybody that's anybody that follows Django development should have heard about the newforms-admin branch landing last Friday. Upon landing, the branch -- being a big, bulky, backwards-incompatible change -- brought about the big headache of having to tediously convert any Django trunk-based code.

But I'd been looking forward to it. Big enhancements in customization were the prime game-changing features.

I noticed a mention of extra hooks in the newforms-admin documentation.

• has_change_permission and the related has_add_permission and has_delete_permission bits -- to specifically set up what users can do to models, based on any logic you want


• more importantly, a queryset hook that allows you to filter out what is displayed to a user in the admin panel. The idea here is that you can be as granular as you want in displaying stuff to a particular user.

Here's a thrown-together example of how I'm planning on using these hooks, based on what I've played around with:

• models.py -- The User foreign key and the permissions give us things to test for...
• admin.py -- ... and the has_change_permission and queryset functions turn that into something useful.

I'm also using extra permissions ('access_all_posts' and 'access_all_blogs') in this example to provide extra permission to users and groups that might need the original (unfiltered) view -- editors, for example. (I'm also providing the same logic to superusers so they have full access all the time, of course.) In both queryset cases, the logic more or less follows such: I make sure to show everything to the people that are supposed to see it all; otherwise, filter out content to blogs that the current (logged in) user owns. Simple as that.

The full list of hooks and options isn't documented yet, but the model code can be looked at, to see for yourself.

This is a pretty rudimentary example, but the hooks are still poorly documented. For anyone with Python experience, the code itself shouldn't be difficult to understand. I'm sure that folks will find more interesting ways to use this, in time.

Update: Forgot to mention a few particulars with the Users you create.

• The "Blog author" (lowest rank) user should receive the edit Blog permission and all (add, edit, delete) BlogPost permissions -- you wouldn't have to worry about users editing/deleting posts that aren't theirs, since you're limiting their view (via queryset) and limiting their permissions outside of the standard Django user permissions interface (via the has_change_permission and has_delete_permission hooks).
• An "editor" user -- someone who should be able to access/change/edit all content -- should receive the standard permissions (add, edit, delete on Blog and BlogPost) but also the special 'access_all_blogs' and 'access_all_posts' permissions.
• Site superusers won't need anything special, as far as I know.

The above applies to groups, as well. Hell, the "author" and "editor" roles can be turned into groups; you know, save yourself from the individual permission-assigning gruntwork.