views:

239

answers:

1

I am developing a Django web application with a suite of steel design tools for structural engineers. There will be a database table of inputs for each design tool, and each row of each table will correspond to a particular design condition to be "solved." The users may work solely or in groups. Each user needs to have ongoing access to his own work so that designs can be refined, copied and adapted, and so that reports can be created whenever convenient, usually at the end of a project when hard copy documentation will be needed. The database contents must then be available over any number of sessions occurring over periods measured in months or even years for a given design project.

When there is a group of users, typically all associated with a given design office, it will probably be acceptable for them all to have joint and mutual access to each other's work. The application supports routine engineering production activities, not innovative intellectual property work, and in-house privacy is not the norm in the industry anyway. However, the work absolutely must be shielded from prying eyes outside of the group. Ideally, each group would have one or more superusers authorized to police the membership of the group. Probably the main tool they would need would be the ability to remove a member from the group, discontinuing his access privileges. This would be a user group superuser and would not be the same as a superuser on the site side.

For convenient access, each row of each database table will be associated with a project number/project name pair that will be unique for a given company deploying a user or user group. A different company could easily choose to use a duplicate project number, and even could choose a duplicate project name, so discriminating exactly which database rows belong to a given user (or group) will probably have to be tracked in a separate related "ownership list" table for each user (or group).

It is anticipated (hoped) that, eventually, several hundred users (or user groups) associated with different (and often competing) companies will solve tens of thousands of design conditions for thousands of projects using these tools.

So, here are my questions:

First, is there any point in trying to salvage much of anything from the Django contrib.auth code? As I perceive it, contrib.auth is designed for authentication and access control that is suitable for the blogosphere and web journalism, but that doesn't support fine-grained control of access to "content."

Second, is there any available template, pattern, example, strategy or design advice I could apply to this problem?

+2  A: 

django-authority

Ignacio Vazquez-Abrams
Ignacio, the concision of your answer compares well with the verbosity of my question! I see that documentation for *django-authority* is in the beginning stages. The section on *Handling permissions in Python code* has yet to be written. I need this as I intend for permissions to be applied automatically in most cases. Are you an expert in the use of django-authority? Would you be willing to consult for an hourly fee? I think I need a coach!
Thomas B. Higgins
I don't know much about it myself, but I've pinged the developer. You could also try the support options given in the documentation if you like. http://packages.python.org/django-authority/support.html#support
Ignacio Vazquez-Abrams
I see here, http://docs.djangoproject.com/en/dev/topics/auth/, that the Django development version has some level of support for object-level (row-level) permissions. I understand this will be finalized in March 2010.
Thomas B. Higgins