Re: Permissions (was: Namespace Security)
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)
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.
Permissions (was: Namespace Security)
This is something we've been thinking a lot about recently. The direction we are considering is something like this: http://github.com/paltman/django-logicaldelete This code, "logical delete," overrides the delete() method of models so that they are simply marked as deleted, and not returned in queryset results. However, an administrator is still able to view the data. Our plan is to use this project as a jumping-off point, and create a scheme (perhaps a Unix-style read/write permission set for user/group/all), and have our models automatically do the right thing. This way, the views and other code don't need to check permissions or do any additional filtering. It's my understanding that record-level permissions is coming in Django 1.2, but we can't wait that long. The goal is to have all the code written as though permissions didn't exist, with the models.Model subclass having special permission functionality behind the scenes that restricted access automatically. Is anyone doing this, or something like it? I don't want to duplicate work, and I'd love to save time if this is a solved problem. Alternately, I'd be happy to test and contribute to such an effort if someone has something rolling already. 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.
