char wrote:
I've seen a couple of approaches on this mailing list for adding
application specific fields to the User class. The first involves
extending auth.User but this seems a little complex, and was
specifically labeled an "advanced" method. It doesn't seem like you
should have to break out deep black magic to do something so standard.
The other method is to have a foreign key pointing to a User. This is
easier but it makes for a messy Admin interface (resulting in both a
User class and a separate MyUser class that needs to be associated with
a User). What is the "canonical" way for extending atuh.User with
application specific fields?
Right now there doesn't seem to be one. It is much easier to just
create a seperate model with a Foreign Key relation. If you use
ForeignKey (as opposed to OneToOne) you can even set the edit_inline and
let the Admin show your object in the main User form. (OneToOne
currently doesn't support that, albeit it really needs the reverse
edit_inline.)
The upcoming Subclassing changes are going to make this route even
easier for OneToOne relationships.
--
--Max Battcher--
http://www.worldmaker.net/
