These are some auth settings and models I propose to account for the generally raised questions for auth.User flexibility.
Settings: - AUTH_USER_EMAIL_UNIQUE If the email should be unique for users. It is a rare case when a website would have users sharing emails. It is more likely other way round that a user has multiple emails. - AUTH_USERNAME_MIN_LENGTH/AUTH_USERNAME_MAX_LENGTH Min and max lengths of the username field. - AUTH_USE_OLD_USER_MODLE If the old style (fn-ln based) user model should be used. Maybe a deprication warning can be provided when this is set to True. Models: - BaseUser Model ~ Current User Model, abstract There will be a base model with all the same fields as current user model but not the first_name and last_name fields. - UNIQUE_EMAIL = getattr(settings,'AUTH_USER_EMAIL_UNIQUE', False) email = EmailField(blank=not UNIQUE_EMAIL, unique=UNIQUE_EMAIL) email column unique/no unique according to AUTH_USER_EMAIL_UNIQUE setting. - A method can be defined which could generate random username while registering if required, like in case of logging in with email, openid, oauth etc. - Provision for authentication through email id can easily be provided if UNIQUE_EMAIL is set. - EnhancedUser, abstract Inherits from BaseUser. Have a field `name` instead of old `first_name`, `last_name`. A single field for name is preferable as it would be more comfortable to users and would also take care of case when the User model doesn't represents an individual but may be a team, an organization etc. Also a text field `description/about` could be provided as it is generally present in basic user profiles everywhere. This would prevent necessity to use a separate Profile model. These fields would result in some minor changes in places like auth.models and auth.admin. The first_name and last_name fields are generally accessed through get_full_name method which could be redefined to return `name`. - OldUser, abstract This with BaseUser will generate the current User model with `first_name`, `last_name` fields and the get_full_name method. In case of an old project, with large database, upgrading to newer django versions. - User This would inherit from EnhancedUser or OldUser according to the AUTH_USE_OLD_USER_MODLE setting and will be the model exposed to other apps, hence there should not be any compatibility issues. Now as far as old projects upgradation to new User model is concerned, that could be done with the help of application 'south'. A migration scripts can be written: 1. Create a column `name`. 2. Create datamigration script to copy `first_name` + `last_name` to `name`. 3. Drop `first_name` and `last_name` column. About Me: I am a 3rd year Engineering undergraduate student from the Department of Agricultural and Food Engineering, Indian Institue of Technology, Kharagpur. I have been using django for a year now and recently started working with the SVN version, hacking the codes of contrib apps and trying to learn the best practices. Website: http://www.rohanjain.in GitHub: http://github.com/crodjer -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
