I see what you're saying, however I still think that groups are the way to go. I think the thing to remember is that, unless the grandchildren actually inherit from your UserProfile, they aren't really "grandchildren" in the sense you mean. They're just instances of the same class, but you want each instance to have different permissions. There is a section of the documentation which references this:
Permissions can be set not only per type of object, but also per specific > object instance. By using the has_add_permission(), has_change_permission() > and has_delete_permission() methods provided by the ModelAdmin class, it is > possible to customize permissions for different object instances of the > same type. It also sounds like what you're really wanting to do is have the creation of one instance of a UserProfile with certain permissions trigger the creation of other instances with difference permissions. This can be achieved by extending the model constructor, with perhaps a method in the UserProfile class to spawn more children? The auth.User model is fairly complicated and, as far as I remember, makemigrations is throwing that ForeignKey error for good reason. However I could be wrong about this, perhaps someone else would be able to clear up things? In any case, if you can get the ForeignKey method to work, that might very well be the easiest solution. If not, using groups should also work. Unfortunately, I don't know enough about the details of Django's auth backend to give you a definitive answer. On Friday, 18 March 2016 17:57:22 UTC-7, Matt Mansour wrote: > > 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] <javascript:>> > 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] <javascript:>> >> 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] <javascript:>. >>> 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.
