3 ms·
Not just contrib.admin, but also contrib.auth. It's very easy to extend the existing user model rather than creating one from scratch. I had to do some unconv
by endtime 14y ago
Not just contrib.admin, but also contrib.auth.
It's very easy to extend the existing user model rather than creating one from scratch. I had to do some unconventional auth stuff recently and I only extended auth.User slightly (and also wrote a slightly modified authentication backend).
- obviouslygreen 14y agoThis feature was something we'd hoped would be awesome; it's not. Going over the documentation shows there's some jaw-dropping nastiness you have to go through to make it work. It's good that they're providing it, but I think the complexity is going to turn people off (I know I won't be using it unless it's simplified at some point in the future). User profiles have always been used for adding data to User models indirectly, and I think this is probably going to remain the best way to handle it for most uses.
- jonknee 14y agoCan you expand on the "jaw-dropping nastiness you have to go through to make it work"? Seems pretty straightforward, though I have not tried to actually use it yet. https://docs.djangoproject.com/en/1.5/topics/auth/customizing/#auth-custom-user https://docs.djangoproject.com/en/1.5/topics/auth/customizin... It appears the database migration is the biggest hurdle, but I don't think there's a way around that. User profiles require a join and that can be suboptimal, which is why this is a useful addition. If you weren't running into problems before it's probably better to not change (though that's usually the case for working code).
- jarcoal 14y agoIn case anyone is considering the migration, it's actually very simple with South. Here is a step-by-step: 1) Setup custom user model to inherit from AbstractUser with no additional fields. 2) Meta.db_table = 'auth_user' on custom user model 3) schemamigration --auto 4) migrate --fake (alternatively comment out statements in migration file and run without fake) Now you can add new fields or change the inheritance to AbstractBaseUser and south will follow along.
- Jasber 14y agoI can't speak for obviouslygreen, but I recently implemented the new User model and was a bit surprised by all the stuff I had to do myself. I just wanted to add one field to the user model, but to do that I had to add 100+ lines of code. I am very happy custom User models are possible now––but for most stuff I'll probably keep using a UserProfile.
- jarcoal 14y agoWhat field were you adding? Are you aware of django.contrib.auth.models.AbstractUser?
- jarcoal 14y agoI've been using custom User models for over a month, and I can tell you that using a profile model is far nastier. Besides avoiding a join in the DB (or worse, a separate select), being able to override user model methods has been an incredible benefit to my projects.
- ra 14y agoYeah I've been using them for about a month too and all I can say is, this is how it should have always been. The docs give you a pretty good starting point for a fully functional user model, and jarcoal (above) outlines a simple method for migrating from old to new.
- masklinn 14y ago> there's some jaw-dropping nastiness you have to go through to make it work. What "jaw-dropping nastinesses" are those, and why didn't you check and report them during the beta/rc phase since you were "hoping it would be awesome"?
- tobych 14y agoA triumph of hope over expostulation.
- nsomaru 14y agoI would also like to hear your thoughts on how this may be improved? Maybe this would be a nice way to contribute to Django...
- jacobian 14y agoI'd love to know more about the "jaw-dropping nastiness" so we can fix it in 1.6. Can you elaborate, please? [I'm a Django committer, FWIW.]
- dnerdy 14y agoI think a common use case that requires a bit of hoop jumping is using an email address in place of a username. Example from the docs: https://docs.djangoproject.com/en/dev/topics/auth/customizing/#a-full-example https://docs.djangoproject.com/en/dev/topics/auth/customizin.... I suspect this may be the nastiness that's being referred to; this is the use case that I was hoping would be made dead simple. With previous versions of Django I generated a random hash for use as a dummy/unguessable username, required an email address in the RegistrationForm, customized the AuthenticationForm, created a custom email authentication backend, and monkey patched User with various helper methods. In 1.5 it looks like the AuthenticationForm will adapt to the field defined in USERNAME_FIELD[1], but a lot of work is still required. Support for easily using email address as the username (or support for easily specifying the username field in general without requiring all the other boilerplate) would probably go a long way. [1] https://docs.djangoproject.com/en/dev/topics/auth/customizing/#custom-users-and-the-built-in-auth-forms https://docs.djangoproject.com/en/dev/topics/auth/customizin...
- jacobian 14y agoThanks, that's a good point. Hopefully we can do something about that in 1.6.