views:

3498

answers:

5

I've been exploring the details of Django for about a week now and like what I see. However I've come upon some.. negativity in relation to fine-grained control of permissions to the CRUD interface.

What I'm writing is an Intranet client management web-app. The organisation is about 6 tiers, and I need to restrict access to client groups based on tiers. Continually expanding. I have a fairly good idea how I'm going to do this, but am not sure if I'll be able to integrate it well into the pre-built admin interface.

I've done absolutely zero Django development otherwise I'd probably have a better idea on whether this would work or not. I probably won't use Django if the generated admin interface is going to be useless to this project - but like I said, there is a heavy reliance on fine-grained custom permissions.

Will Django let me build custom permissions/rules and integrate it seamlessly into the admin CRUD interface?

Update One: I want to use the admin app to minimise the repitition of generating CRUD interfaces, so yes I consider it a must have.

Update Two:

I want to describe the permissions required for this project.

A client can belong to one or many 'stores'. Full time employees should only be able to edit clients at their store (even if they belong to another store). However, they should not be able to see/edit clients at another store. Casuals should only be able to view clients based on what store they are rostered too (or if the casual is logged in as the store user - more likely).

Management above them need to be able to see all employees for the stores they manage, nothing more.

Senior management should be able to edit ALL employees and grant permissions below themselves.

After reading the django documentation, it says you can't (autmoatically) set permissions for a sub-set of a group. Only the entire group. Is it easy enough to mock up your own permissions for this purpose?

+3  A: 

ModelAdmin objects have has_add_permission, has_change_permission, has_delete_permission and queryset methods which can be used to enforce permissions around what the logged-in user can see and modify - you could create a subclass which uses these to enforce whatever permissions you want to implement and register all your models with the admin application using your subclass.

However, it all depends how exactly your permissions system will work - what are the exact requirements which fall out of your fine-grained permissions? The more you move away from what the admin application was designed to do, the more work it'll take, but there are a lot of hooks in there which you can use to implement your custom requirements. Here's a blog post from Luke Plant which gives examples of some of the fine-tuning you can do without having to dig too deep.

Does it absolutely have to be based around the admin application? Generic views and ModelForms can take care of a lot of the tedious bits involved in implementing CRUD , so be wary of getting too hung up on customising admin - it's almost a Django tradition to start by getting hung up on the admin app and what it can and can't do, initially thinking you'll never have to write any code again ;)

insin
A lot of the work is done already with the admin app - that's where a lot of the productivity is going to come from. I just need a way of enforcing who has access to what. See my update above for an example.
Josh Smeaton
+4  A: 

The Django permission system totally rules. Each model has a default set of permissions. You can add new permissions to your models, also.

Each User has a set of permissions as well as group memberships. Individual users can have individual permissions. And they inherit permissions from their group membership.

Your view functions (and templates) can easily check the presence of absence of those permissions at any level of granularity you need to use.

And if this isn't enough for you, the Profile add-on gives you yet more options for defining a "User" and their capabilities, permissions, roles, responsibilities, etc.

And if this isn't enough for you, you can define your own authentication schemes.


What's important is not to try and define groups that are actual subsets of users, not casually defined titles or roles. You never need to "set permissions for a sub-set of a group". You need to have smaller groups. Groups defined around subsets of people.

Django's default permissions are around model access, not row access within a model. On the other hand, your problem is about subsets of rows in several models: Client, Store, Employee, Manager.

You'll need a basic set of FK's among these items, and some filters to subset the rows. You may have trouble doing this with default admin pages. You may need your own version of admin to make use of specialized filters.


If you can't do it with the Django permission system, you should rethink your use cases. Seriously.

[The Django-REST Interface, however, is another beast entirely, and requires some care and feeding.]

S.Lott
+2  A: 

If I read your updated requirements correctly, I don't think Django's existing auth system will be sufficient. It sounds like you need a full-on ACL system.

This subject has come up a number of times. Try googling on django+acl.

Random samplings ...

There was a Summer of Code project a couple of years ago, but I'm not sure where they got to. See http://code.djangoproject.com/wiki/GenericAuthorization

There is a fresh ticket at djngoproject.org that might be interesting:

There is some interesting code snips on dumpz.org:

... but there are zero docs.

Good luck!

Peter Rowell
A: 

You may also want to have a look at the granular-permissions monkeypatch: http://code.google.com/p/django-granular-permissions/

It adds row-level permissions to django's permission system.

bruno desthuilliers
A: 

I've just found http://bitbucket.org/jezdez/django-authority/ , it looks promising.