Re: Virtualenvs and editing contrib stuff manually

On Sat, Oct 6, 2012 at 10:17 AM, Chris Pagnutti
<chris.pagnutti@gmail.com> wrote:
> Hi Russel. Thanks again for your help. I guess "recommend" was the wrong
> word to use. I just mean it's how the docs tell you to do it.
> https://docs.djangoproject.com/en/1.4/topics/auth/#storing-additional-information-about-users

Right - but if you look at the same docs in 1.5:

https://docs.djangoproject.com/en/dev/topics/auth/#storing-additional-information-about-users

You'll see that the AUTH_PROFILE_MODULE technique is marked as deprecated.

> But instead of doing it this way, I just created a new class like this
> class MyUser(User)
> with all the additional fields I wanted, which allows me to use all the auth
> stuff for logging in etc. and it seems to make forms easier. It just felt
> cleaner at the time, but the more I think about it I wonder if there might
> be a reason why this might be bad practice. For example, I don't like how
> creating a new MyUser object makes duplicates in the "MyUsers" and "Users"
> sections of the admin. I haven't tried it, but it seems to me this will
> still be the case if I were to use the foreign key method.

This is actually *exactly* the same method, just with different usage
syntax. Django implements inheritance using a multiple tables and a
foreign key; it just hides those detail from you. So - all you've done
here is implement a MyUser model with a foreign Key to User - you just
didn't need to define it as such.

> What I was trying to do was have Users for the site administrators, and
> MyUsers for site "members", while still taking advantage of all the built-in
> contrib.auth stuff. I would think that this scenario is common enough that
> there is a standard way of dealing with it.

There is - and this is the situation where using profile models is
possibly the right way to handle things (something that the new docs
possibly need to clarify).

What you need to narrow down is the difference between authentication
and profile. Regardless of whether the user is an admin or a member,
they need to identify themselves to the system. For example, every
user, regardless of whether they're a member or an admin, needs to
have an email address so you can contact them. This information is
what needs to go in your User model.

However, once they're logged in, Members have different data to
Admins. Member- or Admin-specfiic data is what should go on the
profile. Admins may have a contact phone number for emergencies, but
members won't; members may have their birthdays stored, but admins
won't. You can then determine whether a user is a member or an admin
by checking for the existence of the appropriate profile model.

This approach has the additional benefit that an admin can be a member
without needing to change accounts - it's just a user that has both a
member and an admin profile.

Yours,
Russ Magee %-)

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.