Dennis and Dan
It does look like more work than can be justified at the moment. And, I
have difficulty seeing a business case for reinventing
django-auth-groups. I really hate the idea of individual permissions but
that would be a possible interim workaround until a case can be made. I
have moved on from this to other conundrums for now.
Thank you both for your responses. They confirm my original thought that
the simpler approach will suffice for the time being.
Cheers
Mike
On 5/02/2012 12:13am, Dan Gentry wrote:
I've solved this problem in an app, but not with the built-in
permissions system. Instead, I created a DB structure that links
users to companies and stores the r/w status for each.
On Feb 3, 12:58 am, Mike Dewhirst<mi...@dewhirst.com.au> wrote:
I want to use the built-in auth_groups permissions system in a
many-to-many sense but can't quite figure it out for my use case. Any
help will be appreciated.
The use case is: users have different types of access (r/o, r/w or
admin) to different companies. Any single user can have r/o access to
company-1, r/w access to company-2 and admin access to company-3 and so
on. Any company can have relationships with many users each of whom will
have one of the r/o, r/w or admin group permissions.
So there has to be a many-to-many relationship between user and company
and the group needs to be specified in that relationship table rather
than in the auth_user_groups table - where it currently sits.
How do I invoke a different set of permissions depending on the name of
the group established in the user-company relationship table when a user
is accessing that company's data?
A side question is how do I remove the displayed Groups in the Django
Admin auth/user display?
Thanks
Mike
On 4/02/2012 3:20am, Dennis Lee Bieber wrote:
On Fri, 03 Feb 2012 17:21:47 +1100, Mike Dewhirst
<mi...@dewhirst.com.au> wrote:
I'm going to simplify the use case and live with users being in the same
group for all companies. This is only a prototype. If a demand arises in
production I'll worry about it then.
Sorry to bother you
If the users were logging into the database itself, I'd probably
have tried to set up the database authorization to provide the
restrictions -- but that would require massive DBA interaction to set up
each user vs company (especially since I suspect "company" incorporates
multiple relations [tables]).
In lieu of that, the brute force approach would be to wrap all
database operations with authorization tests. You don't mention if there
is a possibility for a user to have /no/ access to any given company
(that would complicate matters -- if everyone has read access, you'd
only need to wrap insert/update/delete and admin functions.
Don't know if Django's native database interface can support it (nor
if some RDBM engines could...) but I'm seeing, in raw SQL, something
where a WHERE clause invokes a subselect (I'd have to experiment to get
the proper syntax -- all my books are still in storage)
--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
