Re: Canonical way of handling multiple types of users? (Profiles vs subclassing django.contrib.auth.models.AbstractUser)

2017-06-18 Thread Victor Hooi
Aha, thanks for the good points.

I could go down the route of using auth.groups.

I'd still need a user profile to store the additional fields - are you
thinking I should only have a single Profile class, and make all the fields
nullable?

The issue though is still - how do I integrate this with Google Admin well?
Ideally we'd want different sections to edit teachers, vs students vs
parents - but not sure if this is possible.

On Wed, 14 Jun 2017 at 21:45 Mike Dewhirst  wrote:

> On 14/06/2017 8:59 PM, Victor Hooi wrote:
> > Resurrecting a slightly old thread =), but coming back to this project.
> >
> > Say I have multiple models that each have their own user profile.
> >
> > Let's assume that each type of user is mutually exclusive (i.e. a
> > student cannot be a teacher etc.)
>
> IMO that's a problematic assumption. It is usually best to model real
> life and if you take simplifying shortcuts (i.e. a student cannot be a
> teacher etc.) which don't work out in practice for any reason you end up
> with a project which has to turn itself inside out to keep working.
>
> For me, the "canonical way" would be to use roles. By that I mean
> auth.groups.
>
> I have been bitten before and learned long ago that assumptions related
> to people and what they do/are can be plain wrong.
>
> I would be assuming that a student could also be a teacher. And vice
> versa. And simultaneously! And there's nothing outrageous in that.
> Students often become teachers and as tutors can fill both roles at once.
>
> auth.groups let's you do all sorts of things including role reversals
> and dual roles. You might need object permissions as well if you have
> information silos so that being in a teacher role for one should not
> give unfettered access to a different silo accessed as a student.
>
> In any case, such an approach is usually simpler than software which
> deviates from reality.
>
> That'll be 2c
>
> Mike
>
> >
> > class Student(models.Model):
> > user = models.OneToOneField(User, on_delete=models.CASCADE)
> >
> > class Teacher(models.Model):
> > user = models.OneToOneField(User, on_delete=models.CASCADE)
> >
> > class Parent(models.Model):
> > user = models.OneToOneField(User, on_delete=models.CASCADE)
> >
> >
> > How do you use the Django Admin to manage multiple types of users?
> >
> > The docs mention adding an inline to UserAdmin - however, this seems
> > to assume you only have one model with a user profile - what if you
> > have multiple?
> >
> > Regards,
> > Victor
> >
> > On Monday, 14 November 2016 04:57:53 UTC+11, me.vineetkothari wrote:
> >
> > Use one to many field or many to many field
> >
> > On Wed, Nov 9, 2016 at 3:06 PM, Melvyn Sopacua  > > wrote:
> >
> > Hi,
> >
> > > What is the current canonical way to handle multiple
> > user-profiles in
> > > Django?
> >
> > it highly depends on how you see these objects:
> >
> > 1. different types of users (requirement: a user can only be
> > one type)
> > 2. one type of user with additional information from different
> > sources
> > 3. different types of users, but users can be multiple types
> >
> > Obviously the third is the hardest.
> >
> >
> > On Tuesday 08 November 2016 16:54:43 Victor Hooi wrote:
> >
> > > For example - say you have "Teachers", "Students", "Parents"
> > - you may
> > > have slightly different fields for each one and/or different
> > > behaviour. Students will have things like grades, Parents
> > may have
> > > 1-to-many Students etc.
> >
> > Here you clearly think of them as types, instead of Humans and
> > yet they
> > can fulfill multiple roles. It also doesn't matter what is in the
> > profile, as long as you don't care about enforcing required
> > information
> > at the model layer.
> > You can make one profile model with the union of all fields
> > and use
> > group membership to enforce requirements. So a Human which is
> > member of
> > the Teachers group must have "date_employed" filled in while
> > Student
> > must have "date_enrolled". Similarly, you can use group
> > membership to
> > determine what information to show.
> > Splitting them out in different profiles is a matter of
> > preference and
> > optimization, not of design.
> >
> > > The docs mention using a django.db.models.signals.post_save
> > >
> > <
> https://docs.djangoproject.com/en/1.10/ref/signals/#django.db.models
> > <
> https://docs.djangoproject.com/en/1.10/ref/signals/#django.db.models>.
> > > signals.post_save> signal on User, but I'm guessing that
> > won't work
> > > here if you have multiple types of users.
> >
> > When 

Re: Canonical way of handling multiple types of users? (Profiles vs subclassing django.contrib.auth.models.AbstractUser)

2017-06-14 Thread Victor Hooi
Resurrecting a slightly old thread =), but coming back to this project.

Say I have multiple models that each have their own user profile. 

Let's assume that each type of user is mutually exclusive (i.e. a student 
cannot be a teacher etc.)

>
> class Student(models.Model):
> user = models.OneToOneField(User, on_delete=models.CASCADE)

 

class Teacher(models.Model):
> user = models.OneToOneField(User, on_delete=models.CASCADE) 

 

class Parent(models.Model):
> user = models.OneToOneField(User, on_delete=models.CASCADE)


How do you use the Django Admin to manage multiple types of users?

The docs mention adding an inline to UserAdmin - however, this seems to 
assume you only have one model with a user profile - what if you have 
multiple?

Regards,
Victor

On Monday, 14 November 2016 04:57:53 UTC+11, me.vineetkothari wrote:
>
> Use one to many field or many to many field
>
> On Wed, Nov 9, 2016 at 3:06 PM, Melvyn Sopacua  > wrote:
>
>> Hi,
>>
>> > What is the current canonical way to handle multiple user-profiles in
>> > Django?
>>
>> it highly depends on how you see these objects:
>>
>> 1. different types of users (requirement: a user can only be one type)
>> 2. one type of user with additional information from different sources
>> 3. different types of users, but users can be multiple types
>>
>> Obviously the third is the hardest.
>>
>>
>> On Tuesday 08 November 2016 16:54:43 Victor Hooi wrote:
>>
>> > For example - say you have "Teachers", "Students", "Parents" - you may
>> > have slightly different fields for each one and/or different
>> > behaviour. Students will have things like grades, Parents may have
>> > 1-to-many Students etc.
>>
>> Here you clearly think of them as types, instead of Humans and yet they
>> can fulfill multiple roles. It also doesn't matter what is in the
>> profile, as long as you don't care about enforcing required information
>> at the model layer.
>> You can make one profile model with the union of all fields and use
>> group membership to enforce requirements. So a Human which is member of
>> the Teachers group must have "date_employed" filled in while Student
>> must have "date_enrolled". Similarly, you can use group membership to
>> determine what information to show.
>> Splitting them out in different profiles is a matter of preference and
>> optimization, not of design.
>>
>> > The docs mention using a django.db.models.signals.post_save
>> > > > signals.post_save> signal on User, but I'm guessing that won't work
>> > here if you have multiple types of users.
>>
>> When you have multiple *profiles* this will work just fine. It's also
>> not a big problem to solve, because user creation and updating is not an
>> uncontrollable process like the docs suggest.
>> User creation via commandline or automated process really only happens
>> in tests and backup restore procedures.
>>
>> In production it's your job to properly set permissions for meddling
>> with users in the admin and to provide forms that include relevant
>> profile information. When providing good forms the signal is actually
>> disruptive: you already have the information available, you save the
>> user then save the profile information. Having a signal fire that
>> doesn't have access to that profile information is not very useful and
>> can lead to validation errors simply because the handler doesn't have
>> the context.
>>
>> > Or are you better off subclassing
>> > django.contrib.auth.models.AbstractUser? (I get the impression using
>> > profile models is less invasive).
>>
>> The case for subclassing is really only one:
>> Do you not have the right information in the standard user model to
>> authenticate the user?
>> Highly specialized cases aside, it's better to use profiles.
>>
>> A prominent example for not having the right information is when
>> authentication happens with SSL certificates rather then
>> username/password. Another is having different authentication servers
>> and what server to use is depending on a field that isn't in the user
>> model, like "faculty" or "signup_date.year".
>>
>> Hope this helps,
>> --
>> Melvyn Sopacua
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-users...@googlegroups.com .
>> To post to this group, send email to django...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-users.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/1678108.SszHfPmntC%40devstation
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 

Re: Canonical way of handling multiple types of users? (Profiles vs subclassing django.contrib.auth.models.AbstractUser)

2016-11-13 Thread Vineet Kothari
Use one to many field or many to many field

On Wed, Nov 9, 2016 at 3:06 PM, Melvyn Sopacua 
wrote:

> Hi,
>
> > What is the current canonical way to handle multiple user-profiles in
> > Django?
>
> it highly depends on how you see these objects:
>
> 1. different types of users (requirement: a user can only be one type)
> 2. one type of user with additional information from different sources
> 3. different types of users, but users can be multiple types
>
> Obviously the third is the hardest.
>
>
> On Tuesday 08 November 2016 16:54:43 Victor Hooi wrote:
>
> > For example - say you have "Teachers", "Students", "Parents" - you may
> > have slightly different fields for each one and/or different
> > behaviour. Students will have things like grades, Parents may have
> > 1-to-many Students etc.
>
> Here you clearly think of them as types, instead of Humans and yet they
> can fulfill multiple roles. It also doesn't matter what is in the
> profile, as long as you don't care about enforcing required information
> at the model layer.
> You can make one profile model with the union of all fields and use
> group membership to enforce requirements. So a Human which is member of
> the Teachers group must have "date_employed" filled in while Student
> must have "date_enrolled". Similarly, you can use group membership to
> determine what information to show.
> Splitting them out in different profiles is a matter of preference and
> optimization, not of design.
>
> > The docs mention using a django.db.models.signals.post_save
> >  > signals.post_save> signal on User, but I'm guessing that won't work
> > here if you have multiple types of users.
>
> When you have multiple *profiles* this will work just fine. It's also
> not a big problem to solve, because user creation and updating is not an
> uncontrollable process like the docs suggest.
> User creation via commandline or automated process really only happens
> in tests and backup restore procedures.
>
> In production it's your job to properly set permissions for meddling
> with users in the admin and to provide forms that include relevant
> profile information. When providing good forms the signal is actually
> disruptive: you already have the information available, you save the
> user then save the profile information. Having a signal fire that
> doesn't have access to that profile information is not very useful and
> can lead to validation errors simply because the handler doesn't have
> the context.
>
> > Or are you better off subclassing
> > django.contrib.auth.models.AbstractUser? (I get the impression using
> > profile models is less invasive).
>
> The case for subclassing is really only one:
> Do you not have the right information in the standard user model to
> authenticate the user?
> Highly specialized cases aside, it's better to use profiles.
>
> A prominent example for not having the right information is when
> authentication happens with SSL certificates rather then
> username/password. Another is having different authentication servers
> and what server to use is depending on a field that isn't in the user
> model, like "faculty" or "signup_date.year".
>
> Hope this helps,
> --
> Melvyn Sopacua
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-users/1678108.SszHfPmntC%40devstation.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAAcanssSwCF48tS_HKisWfr-QRjCTtQFUL8uPZHqN1xqNr3NPw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Canonical way of handling multiple types of users? (Profiles vs subclassing django.contrib.auth.models.AbstractUser)

2016-11-09 Thread Melvyn Sopacua
Hi,

> What is the current canonical way to handle multiple user-profiles in
> Django?

it highly depends on how you see these objects:

1. different types of users (requirement: a user can only be one type)
2. one type of user with additional information from different sources
3. different types of users, but users can be multiple types

Obviously the third is the hardest.

 
On Tuesday 08 November 2016 16:54:43 Victor Hooi wrote:

> For example - say you have "Teachers", "Students", "Parents" - you may
> have slightly different fields for each one and/or different
> behaviour. Students will have things like grades, Parents may have
> 1-to-many Students etc.

Here you clearly think of them as types, instead of Humans and yet they 
can fulfill multiple roles. It also doesn't matter what is in the 
profile, as long as you don't care about enforcing required information 
at the model layer.
You can make one profile model with the union of all fields and use 
group membership to enforce requirements. So a Human which is member of 
the Teachers group must have "date_employed" filled in while Student 
must have "date_enrolled". Similarly, you can use group membership to 
determine what information to show.
Splitting them out in different profiles is a matter of preference and 
optimization, not of design.

> The docs mention using a django.db.models.signals.post_save
>  signals.post_save> signal on User, but I'm guessing that won't work
> here if you have multiple types of users.

When you have multiple *profiles* this will work just fine. It's also 
not a big problem to solve, because user creation and updating is not an 
uncontrollable process like the docs suggest.
User creation via commandline or automated process really only happens 
in tests and backup restore procedures.

In production it's your job to properly set permissions for meddling 
with users in the admin and to provide forms that include relevant 
profile information. When providing good forms the signal is actually 
disruptive: you already have the information available, you save the 
user then save the profile information. Having a signal fire that 
doesn't have access to that profile information is not very useful and 
can lead to validation errors simply because the handler doesn't have 
the context.

> Or are you better off subclassing
> django.contrib.auth.models.AbstractUser? (I get the impression using
> profile models is less invasive).

The case for subclassing is really only one:
Do you not have the right information in the standard user model to 
authenticate the user?
Highly specialized cases aside, it's better to use profiles.

A prominent example for not having the right information is when 
authentication happens with SSL certificates rather then 
username/password. Another is having different authentication servers 
and what server to use is depending on a field that isn't in the user 
model, like "faculty" or "signup_date.year".

Hope this helps,
-- 
Melvyn Sopacua

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/1678108.SszHfPmntC%40devstation.
For more options, visit https://groups.google.com/d/optout.


Re: Canonical way of handling multiple types of users? (Profiles vs subclassing django.contrib.auth.models.AbstractUser)

2016-11-08 Thread Mike Dewhirst

On 9/11/2016 11:54 AM, Victor Hooi wrote:

Hi,

What is the current canonical way to handle multiple user-profiles in 
Django?


For example - say you have "Teachers", "Students", "Parents" - you may 
have slightly different fields for each one and/or different 
behaviour. Students will have things like grades, Parents may have 
1-to-many Students etc.


I understand you can use a OneToOne field to associated different user 
profiles with each type of user:


If a Parent is also a Teacher then you would need two profiles for that 
parent. Personally, I like profiles in a OneToOne relationship with the 
user (or custom user) model but for different sets of characteristics I 
would use multiple tables and make each of them OneToOne with user.


If they were somewhat similar I would separate out all the common fields 
and methods and make an abstract CoreFields model and inherit that in 
each of the different profile models. For example 
StudentProfile(CoreFields), TeacherProfile(CoreFields) 
ParentProfile(CoreFields) and so on. That would let you have more than 
one profile per user.


I'm not sure about canonical in this context. The zen of python is 
probably your best guide.


Mike



https://docs.djangoproject.com/en/1.10/topics/auth/customizing/#extending-the-existing-user-model

The docs mention using a django.db.models.signals.post_save 
 
signal on User, but I'm guessing that won't work here if you have 
multiple types of users.


Or are you better off subclassing 
django.contrib.auth.models.AbstractUser? (I get the impression using 
profile models is less invasive).


Regards,
Victor
--
You received this message because you are subscribed to the Google 
Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to django-users+unsubscr...@googlegroups.com 
.
To post to this group, send email to django-users@googlegroups.com 
.

Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/314de801-0ca7-4eb3-abb9-7a3044994bcd%40googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/f7edf132-fc56-d1fb-06a5-bbd80e99ec17%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.


Canonical way of handling multiple types of users? (Profiles vs subclassing django.contrib.auth.models.AbstractUser)

2016-11-08 Thread Victor Hooi
Hi,

What is the current canonical way to handle multiple user-profiles in 
Django?

For example - say you have "Teachers", "Students", "Parents" - you may have 
slightly different fields for each one and/or different behaviour. Students 
will have things like grades, Parents may have 1-to-many Students etc.

I understand you can use a OneToOne field to associated different user 
profiles with each type of user:

https://docs.djangoproject.com/en/1.10/topics/auth/customizing/#extending-the-existing-user-model

The docs mention using a django.db.models.signals.post_save 

 
signal on User, but I'm guessing that won't work here if you have multiple 
types of users.

Or are you better off subclassing django.contrib.auth.models.AbstractUser? 
(I get the impression using profile models is less invasive).

Regards,
Victor

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/314de801-0ca7-4eb3-abb9-7a3044994bcd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.