#10686: 2 simple improvements to permission inheritance.
------------------------------------------+---------------------------------
 Reporter:  faldridge                     |       Owner:  nobody    
   Status:  new                           |   Milestone:            
Component:  Database layer (models, ORM)  |     Version:  SVN       
 Keywords:  permissions inheritance       |       Stage:  Unreviewed
Has_patch:  1                             |  
------------------------------------------+---------------------------------
 I've got a patch for a slight behavior modification that I needed and that
 might be useful for others, and I wanted to collect some thoughts on it
 before writing up the regression tests and documentation changes.

 Twice now, I've come across a situation where the default Django behavior
 for inheriting permissions is inappropriate for my security model.

 Here's the situation: I have a permission on an abstract base model class
 that I want all child classes to inherit, and I want to then append
 specific permission(s) to one or more of the children.

 Example:
 {{{
 #!python
 class MyAppBaseModel(models.Model):
     class Meta:
         abstract = True
         permissions = (("view_%(class)s", "Can view %(class)s"),)

 class ChildModel(MyAppBaseModel):
     class Meta:
         permissions =  (("foobar_childmodel", "Can foobar childmodel"),)
 }}}

 Two problems arise:
     1.  Although permissions currently may be inherited, the Options class
 does not currently implement %(class)s replacement like the RelatedField
 class does, so my permissions end up actually being stored in the database
 with %(class)s in the name and codename.
     2.  The way Meta attributes are currently processed in the ModelBase
 metaclass causes inherited permissions to be completely replaced if any
 explicit permissions are defined on the child class.  So instead of
 can_view and can_foobar on ChildModel, I only get can_foobar.


 This patch changes Django's behavior such that any explicit child class
 permissions would be appended to the inherited ones, rather than
 completely replacing them.

 Also, I've added a backwards-compatible flag to the Meta options,
 'inherit_permissions'.  This flag would only be required in the case that
 one wanted Django's current behavior which is to discard base class
 permissions when explicit permissions are declared on the child class.

 Example:
 {{{
 #!python
 class MyAppBaseModel(models.Model):
     class Meta:
         abstract = True
         permissions = (("view_%(class)s", "Can view %(class)s"),)

 class ChildModel(MyAppBaseModel):
     class Meta:
         permissions =  (("foobar_childmodel", "Can foobar childmodel"),)
         inherit_permissions = False
 }}}

 This would result in ChildModel only having the can_foobar permission
 (Django's current behavior).  If you wanted to inherit/append the
 view_class
 permission instead (proposed behavior), you could set the attribute to
 True or leave it out entirely.

 This, of course, assumes that my desired behavior is what most other
 people would want.  I suspect, but am not certain that this is the case.

 Though a small change, I believe it requires a design decision.

 Thanks!

-- 
Ticket URL: <http://code.djangoproject.com/ticket/10686>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to