Hi All -
Here's the relevant code in UserProfile model
class UserProfile(models.Model):
user = models.OneToOneField('auth.User', blank=True, null=True,
related_name='userprofile')
owner = models.ForeignKey('auth.User', blank=True, null=True,
related_name='subordinates')
When I makemi
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
Thanks for asking btw!
On Mar 18, 2016 5:16 PM, "Matt Mansour" 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" wrote:
>
>> Hi Matt,
>>
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" wrote:
> That sounds close but I'm not sure it's granular enough. For example an
> owner can only edit t
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
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
edi
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" wrote:
> Hi Matt,
>
> It might be useful if you explain what you're trying to do. For example,
> why d
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 installe
