Hi Moritz, Thanks for your proposal! Here's my feedback.
On 14 avr. 2012, at 01:56, Moritz S. wrote: > I found out about GenericRelations from the contenttypes framework. So you > could possibly use a single model called 'ObjectPermissions' or something and > link users, permissions and instances of all types of models and only had to > use one GenericRelation. This solution eliminates the problem wit the dynamic > models because it doesn't even make use of them. This solution is the "simplest one that could possibly work", and as such, it's my favorite. > But the GenericRelations have another not negligible disadvantage: The > databases behind django don't have native support for them. I thought of huge > django projects handling thousands and thousands of object permissions. I > think these GenericRelations wouldn't be such scalable to make use of them. With an appropriate index, SQL databases should be able to find rows matching a condition on two columns about as quickly as if the condition was only on one column, even in a table containing million of objects. I'd like to see a benchmark before rejecting this idea on performance grounds. Could you point us to some data supporting your assertion that this isn't scalable? > The only solution for me was to find a way to link the (unknown) model > instances to the permissions in the reversed direction. So not use > ForeignKeys, etc. in the permission model to refer to the unknown model but > to refer from the model to the permission itself. That would fix the problem > of not knowing the models while creating the permission model. So in the end > I thought of following: > - there is a new model in the auth module called 'ObjectPermission' this > model has ManyToManyFields to User and Group and a ForeignKey to Permission > - instead of ObjectPermission referring to the model using object > permissions, a field called 'object_permissions' is added to the > corresponding models (by use of the class_prepared signal) (dynamically > adding fields is way better than use completely dynamic models in my opinion) > - the object_permissions field is a ManyToManyField, that refers to > ObjectPermission. In fact, a 'ManyToOneField' would be sufficient but django > only has one to many fields (the ForeignKeyField) and we can't just use this > in the reversed direction, as I mentioned above I'm -1 on a contrib app (django.contrib.auth) injecting a dynamic field into every model. (Yes, Django does that for the primary key, to avoid declaring it in every model. But it's core, not a contrib app.) > Furthermore I thought of slightly modifying the auth module (apart from the > ObjectPermission model) in the following way: > - when the auth app is initialized a function is registered to listen to the > class_prepared signal. This function adds the object_permissions field to > each model, that has the Meta.object_permissions set to True (for this to > work, this meta attribute has to be set in django.db.models.options) What's the definition of "when the auth app is initialized"? Wouldn't your solution required that django.contrib.auth be loaded before all other apps? > - the User model gets the methods grant_perm and revoke_perm that takes the > permission and as optional argument the object in order to simplify the > process of handling permissions With the solution that I prefer, this doesn't seem absolutely necessary, the following statements are simple enough: ObjectPermission.objects.create(user=user, object=instance) ObjectPermission.objects.get(user=user, object=instance).delete() > - in the ModelBackend the methods has_perm, etc. have to be modified to be > able to handle function calls with given objects (obviously) Yes. Best regards, -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
