Would including a built-in contrib app that implements access control
lists be outside the scope of Django?
I figure a design similar to the current admin site will be needed to
create a generic ACL subsystem. An access list would be defined for each
app, similar to how an admin site is defined in admin.py. I'm willing to
spend some time on this, but I'd like any opinions as to the best way to
implement it before I spend more than a weekend or two on this idea.
I don't think that there is a Django ACL implementation quite like I
have in mind. Most ACL functionality I imagine is written in views that
go with a specific app. A standard implementation of ACL in contrib one
would allow for more pluggable pluggable apps.
Let me know what you think!
Thanks!
Jeff Anderson
It may not be. However, this isn't really the right question to ask. The
right question is "why has nobody built the kick-ass implementation that
everybody needing this is prepared to walk across hot coals to use
because it's so wonderful?" Something like this doesn't need to be in
Django. Maybe not ever, but certainly not initially. Django is designed
so that external applications are easy to develop and don't need core
modifications. If it's built and isn't included in Django, nobody is any
worse off, because it still exists.
For good reason, we try very hard not to give advance commitment to
acceptance of anything before it exists externally. There have
historically been some very rare exceptions, but are just that:
exceptions.
If, in the process of developing said application, problems appear that
justify generalisations of abstractions being made to core, discussions
appear here and things happen. That has happened in the past and will
happen again in the future. In this case, for example, it might turn out
that some kind of subclass overriding isn't possible in the admin and
making something finer-grained to allow extensions might not be a bad
idea.
I'm also thinking that requiring evidence of people walking across hot
coals in order to use an application is probably a good pre-requisite
for inclusion in django.contrib.
Regards,
Malcolm
+1
The gmail ads are conveniently offering me 'Firewalk Teacher Training'
and 'Find a Fire-Walk near you', so this shouldn't be too hard to
organise :-)
The basic idea is to create a new PermissionedModel class, that can be
used just as the standard Model. The PermissionedModel automatically
checks if the current user has permissions to do some operation (View,
Create, Update, Delete, or possibly some custom operation). Permissions
are defined using a quite lax syntax, which should allow for row-based,
column-based, or any filter-based permissions.
If there anyone wants to help get this project going again, or willing
to test it in some semi-production environment, let me know :)
Regards,
tie