views:

176

answers:

2

Background

I'm developing a django app for a vacation rental site. It will have two types of users, renters and property managers.

I'd like the property managers to be able to manage their rental properties in the django admin. However, they should only be able to manage their own properties.

I realize the default django admin doesn't support this. I'm wondering how much trouble it would be to add this functionality, and, if it's feasible, what the best way to handle it is.


Goal

Ideally, I picture it working something like this:

auth already allows permissions like this:

vacation | rental | Can add rental
vacation | rental | Can change rental
vacation | rental | Can delete rental

I'd like to change this to something like:

vacation | rental | Can add any rental
vacation | rental | Can change any rental
vacation | rental | Can delete any rental
vacation | rental | Can add own rental
vacation | rental | Can change own rental
vacation | rental | Can delete own rental

Possible solution

How would the framework decide if the rental (or whatever) belongs to the user? I'm thinking it checks the vacation.Rental class to see if it has a ForeignKey to auth.User (possibly having some particular name, like 'owner').

  • On creating a new vacation.Rental, the value of the ForeignKey field would be forced to the current user's id. The ForeignKey field would not be displayed on the form.

  • On listing rentals, only rentals with the ForeignKey matching the current user would be displayed.

  • On changing rentals, only rentals with the ForeignKey matching the current user would be displayed. The ForeignKey field would not be displayed on the form.

Of course, this should be able to work for any model having an appropriate ForeignKey field, not just our vacation.Rental model.

Does this sound feasible so far, or should I be going in a different direction?


Complications

Now, here's the tricky part; I'm not sure how to handle this. Let's say a Rental can have many "RentalPhotos." RentalPhoto has a ForeignKey to Rental. Users should be able to add photos to their own rentals. However, the photos don't have a user ForeignKey, so there's no way to directly find out who owns the photo.

Can this be solved by some trickery in the framework, following ForeignKeys until an object is found with a ForeignKey to user? Or should I take the easy way out and give RentalPhoto (and everything else 'belonging' to Rental) its own ForeignKey to the appropriateauth.User? The second approach would invite unneeded redundancy, the first would probably require unnecessary processing overhead...

If I'm going entirely astray please don't hesitate to point me in the right direction. Thanks in advance for any help.

+1  A: 

Can this be solved by some trickery in the framework, following ForeignKeys until an object is found with a ForeignKey to user?

I don't see where there is trickery necessairy: RentalPhoto -> Rental -> User So to get the User for a particular RentalPhoto you would call something like this in the instance:

photo.rental.user

Following multiple relations in one step can be considered as non-trickery.

Andre Bossard
That would work for this particular case, but I want to do it in a generic way -- "Of course, this should be able to work for any model having an appropriate `ForeignKey` field, not just our `vacation.Rental` [and related] model[s]."
no
There are like dozends of possible ways to be more generic. E.g. having a model.Ownable which defines the field owner and extend it in the ownable Models.
Andre Bossard
This answer isn't very helpful. It leaves most of the question unanswered. Maybe I did a bad job of explaining the question?
no
If you can tell me why using model inheritance doesn't help your case, I better understand what your problem is.
Andre Bossard
+2  A: 

I would simply add a method to each model isOwndedBy(user), and it is upto the model to decide if it is owned by that user or not. In most case isOwndedBy can be a generic function in a base model class and you can tweak it in special cases. e.g.

class RentalPhoto(BaseModel):
    def isOwnedBy(self, user):
        return self.rental.isOwnedBy(user)

This is generic enough and being explicit you will have full control how things behave.

To add new permission you can add that to your models e.g.

class Rental(models.Model): # ... class Meta: permissions = ( ("can_edit_any", "Can edit any rentals"), )

I think instead of adding two permission for any and own, you should add only own permission , so each object already has can_edit which you can treat as user can only his object, and if user has permission can_edit_any than only he is allowed to edit all

Using this we can extend auth by adding a custom backend e.g.

class PerObjectBackend(ModelBackend):

    def has_perm(self, user_obj, perm, obj=None):
        allowed = ModelBackend.has_perm(self, user_obj, perm)
        if perm.find('any') >=0 :
            return allowed

        if perm.find('edit') >=0 or perm.find('delete') >=0:
            if obj is None:
                raise Exception("Perm '%s' needs an object"%perm)
            if not obj.isOwnedBy(user_obj):
                return False

        return allowed

This is a very quick implemenation, in reality you can extend permission objects to check if it needs and object or not e.g. permission.is_per_object instead of doing crude string search but that should also work if you have standard names

Anurag Uniyal
Thanks, Anurag; it's not as generic as I'd like but I'll consider it. How can I tie this into `auth` so my new permissions show up in the list?
no
@no see the edit.
Anurag Uniyal