With that it seems like creating a custom permissions would be trivial with with foreign Keys pointing to User for the different ownership relationships On Mar 18, 2016 5:53 PM, "Matt Mansour" <[email protected]> wrote:
> 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.
