Re: auth groups puzzle

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
> <miked@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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.