That sounds close but I'm not sure it's granular enough. For example an owner can only edit the profiles that has been assigned to him. E.g Owner A owns - and can only edit objects B, C and D. Owner E owns F G and H. And yes both those owners can have a superior over them and should be able to edit the grandchildren and the owners. All of which are not staff On Mar 18, 2016 5:36 PM, "Avery Laird" <[email protected]> wrote:
> No problem! Mezzanine uses Django's permission system, which is probably > the best way to go in this situation (if I understand what you're trying to > do). See the documentation: "three default permissions – add, change and > delete – are created for each Django model defined in one of your installed > applications." You have the "subordinate" profile type, and a group of > users that can edit the "subordinate" profile type. When creating a new > user, Mezzanine displays these three default permissions for all models you > have created. For example, I also have a custom User Profile class, so > there is a permission displayed "<app label> | User Profile | Can > add/change/delete User Profile |." That means, you can create a group which > has only the permissions you want. > > However, if you want to have the users arranged in a tier of some sort, > which any relationship more complicated than what I described above, you > may want to look in to creating your own groups/permissions. You can find > the documentation here > <https://docs.djangoproject.com/en/dev/topics/auth/default/#permissions-and-authorization> > . > > On Friday, 18 March 2016 17:18:22 UTC-7, Matt Mansour wrote: >> >> Thanks for asking btw! >> On Mar 18, 2016 5:16 PM, "Matt Mansour" <[email protected]> wrote: >> >>> The additional foreignkey back to user is designated users who have >>> permission to edit the profiles of only their subordinates. These owners >>> are non staff >>> On Mar 18, 2016 3:49 PM, "Avery Laird" <[email protected]> wrote: >>> >>>> Hi Matt, >>>> >>>> It might be useful if you explain what you're trying to do. For >>>> example, why do you need the foreign key relationship back to auth.User? >>>> I'm having trouble imagining a situation where you'd need both a OneToOne >>>> relationship and a ForeignKey relationship to the same model. Maybe you can >>>> accomplish your task a different way. >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Mezzanine Users" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- > You received this message because you are subscribed to the Google Groups > "Mezzanine Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Mezzanine Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
