Too much fields in User model

[samozvanezz@…]

I think there's too much fields in base User model.
The only required fields for authorization purposes are username, password and, possibly, is_active flag. So I think others should be removed (Yes, I know that other fields are optional). Why store in basic athentification model some additional data that isn't needed for athentification?
With the new cool inheritance features you work on, it will be quite easy to extend base class with new fields.
If you think that firstnames, lastnames and e-mails are very common, you're defenitely right. So you could make some model (Staff, for example), wich extends basic User with this fields and include it in django distribution. So if one needs just auth(entification|thorization), he would use base User class. Other would use built-in Staff class. And someone else would derive a custom class from basic User with exactly such fields, as he needs.
Even if part of my users are robots, that have only model and version parameters, part of them are humans with common firstname and lastname and another part are programmers wich have only email, I could build a custom model for each of them, not giving up the power of django's athentification system.

[James Bennett <ubernostrum@…>]

Just because it's obligatory for me to do this everywhere the question pops up:

Subclassing does not solve the problem of adding new fields to the User model; it's unclear yet whether the final API will have queries for User retrieve instances from all of its subclasses (see the django-developers thread on this for more information[1]), for example.

[1] ​http://groups.google.com/group/django-developers/browse_thread/thread/7d40ad373ebfa912/a20fabc661b7035d

[samozvanezz@…]

I'm not a django developer, of course, just a user, but I think it shouldn't. As for me, the base class doesn't need to know anything about it's subclasses.
Why retrieve an instances of subclasses trough Users API?

For example, you have just very simple User model, as I described above. Then you subclassing an Employee model, that have additional fields, like firstname and lastname. You don't use the basic model for typical site users' administration! You will add, change and delete Employees trough admin interface instead!

In this case, there's no need to call Employee's fields and methods trough User API, because you deal only with Employees, wich of course have full access to User's fields needed for authorization purpouses.
So why the hell I need this simplyfied User class, if I get the same model as in current django version as a result?!
Because it's more clear, logical and extensible. And this is a django-way. :)

[Alexey Solyanik <samozvanezz@…>]

There still may be situations, when you need to retreive instances of subclasses. But I think in such cas you can use specific function (like As), wich will handle lookups trough subclasses tables.

guy = Employee(firstname='Bar', lastname='Fooman')
guy.save()
print User.object.all().As(Employee).lastname

This fucntion will look in Employee table for records with given user_id, and return Employee instances.

[Malcolm Tredinnick]

In its current form, this ticket isn't very useful. Model inheritance won't solve the problem that the Admin interface instantiates a User class, not a subclass of user, for example.

There's nothing to "fix" in the current ticket. After model inheritance has landed, if somebody wants to work out a concrete patch for changing Admin to use subclassing somehow, we can address that then.