Re: Permissions (was: Namespace Security)

[Shawn Milochik]

Tim,

I think that if you replace the term "namespace" with "group," we can do what 
we both want with the same solution. Or, in other words, we're kind of saying 
the same thing but using different words.

In my scenario, each user would be in one or more groups. Each user could read 
or write anything they created. They could read or write things other people in 
the same group created (permissions allowing). If course, people can be in 
multiple groups. Exactly the same as the user permissions in *nix, rwx 
(read/write/execute) for ugo (user/group/other), except that I don't think 
'execute' really applies.

I think each model would have "hidden" fields for group and owner (creator), as 
the "logical delete" author created for deletion date. Each user would have a 
many-to-many with the same groups, and read and/or write permissions for those 
groups. This would be added by taking advantage of the AUTH_PROFILE_MODULE 
Django makes available.
http://docs.djangoproject.com/en/dev/topics/auth/#auth-profiles

Everything above would be ridiculously easy to implement. The rest (subclassing 
models.Model to enforce the behavior) might be pretty simple as well, but I 
haven't really rooted around in the Django internals enough to know how 
involved it is. Also, I could be missing a couple of steps if additional work 
is required to make it play nicely in the admin.

Does this line up with your vision, or is there a contradiction in goals?

Shawn-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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.

Re: Permissions (was: Namespace Security)

[Tim]

That looks like a pretty good starting point. It's a little different
in that for my scenario, UserA and UserB would both be accessing
django admin, but would get different results based on what Namespaces
they have access to.

Seems like it should be pretty easy to create a Model Admin that
overwrites the has_*_permission functions and the queryset funtion.
Given the model above, this prevents users from editing objects that
are not in a namespace they have access to.

class NamespacedAdmin(admin.ModelAdmin):
def has_change_permission(self, request, obj=None):
if obj and not ( obj.namespace in
request.user.namespace_set.all() ):
return False
return super(NamespacedAdmin, self).has_change_permission
(request, obj)

The has_add_permission(self, request) function looks to be more
tricky, since it doesn't accept an obj instance. Maybe some more
overwriting of the ModelAdmin functions could resolve that.
-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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.