I continue to struggle with what I see as some real limitations of the
User/UserProfile paradigm used by Django.
The recommended policy of setting AUTH_PROFILE_MODULE works alright
for situations where the applications in your site only have need of a
single user type.
I've been working on a project where there are at least three distinct
types of Users and I've spent quite a lot of time trying to come up
with a seamless way for say, a school administrative assistant, to add
people/users to the site.
One issue, which I have seen a number of people struggling with is the
usability of the Users selection widget. The problem is that when
creating users, there are no required fields that make for easy
ordering, searching or readability. If first_name, last_name were
required, they could be used to make the selection widget order-able
and more readable. Of course, no one wants to have Django hardwire
anything but the bare minimum fields for the authentication system so
this is understandable.
Setting the 'edit_inline' option for your UserProfile (or whatever you
call it) model mitigates this somewhat because you can set the profile
fields at the same time that you create the user. I'm guessing most
people do it this way.
Because I want administrators of the site to have an easy way to give
Users a choice of different profiles, I've had to try some different
approaches.
I created an app called people that other apps will reference to get
user info.
Then,
I tried subclassing my UserProfile model. I set AUTH_PROFILE_MODULE =
people.UserProfile
class UserProfile(models.Model):
first_name = models.CharField(max_length=30, core=True)
last_name = models.CharField(max_length=30, core=True)
email = models.EmailField()
class Meta:
abstract = True
class Teacher(UserProfile):
users = models.ForeignKey(Users, unique=True, edit_inline=True)
home_phone = models.PhoneNumberField(blank=True)
department = models.CharField(max_length=60, blank=True)
etc.
class Parent(UserProfile):
users = models.ForeignKey(Users, unique=True, edit_inline=True)
home_phone = models.PhoneNumberField(blank=True)
etc.
class Student(UserProfile):
users = models.ForeignKey(Users, unique=True, edit_inline=True)
parents = models.ManyToManyField(Parent)
class_year = models.CharField(max_lenght=4, blank=True)
This works, except:
-I want the 'users' foreign key to be set on each child rather than
on UserProfile, so that a user can fill more than one role (teacher
may also be a parent.) This breaks get_profile(), the use of which was
part of the point in the first place.
- All of the child user types show up in the add/change admin for
users. The administrator would have to remember what type of user they
were adding and do a lot of scrolling around irrelevant fields.
- There are the redundant first_name, last_name fields. You can leave
them out of your profiles models, but then listing pages for your
various user types lose their typical ordering and search fields.
With multiple user types, it would be much easier to associate/create
a user inside user type model's add page. But,
-if the user already exists, we say hello again to the unfriendly
user selection widget
-if the user doesn't exist, (which would be the general case if you
came this way to add people to the system) the little green cross will
let us add one, but we will have to reload our 'add' page to have the
addition show up.
It seems to me, that one way to solve this would be to enable the
registration of multiple profiles which could then be offered as
choices at user creation.
Has anyone else experienced clunkyness in the matching of Users with
People Of A Particular Ilk using the admin interface?
Does NewformsAdmin have any bearing on this sort of issue?
Dan J.
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
