Re: Custom user models don't like non integer primary keys.

Ticket #14881 addresses the issue that django.contrib.auth assumes User.pk is an integer and thus password reset doesn't work. I've updated the original patch and added documentation and a backwards compatibility proposal. Reviews and feedback

Re: Custom user models don't like non integer primary keys.

Sorry for disappearing there. I didn't think a full trace was necessary, russ nailed that particular instance. As a user of django, I don't think for 1.5 that you need to change the behavior of views. It just blind sided me that the custom auth model needed an integer ID and it should be added

Re: Custom user models don't like non integer primary keys.

On Wed, Nov 7, 2012 at 12:06 AM, Russell Keith-Magee wrote: > Hi Eric, > > Although the full stack trace would confirm it, I think I can guess what the > problem is here -- it's the mechanism for generating reset tokens. > > If you dig into the token generation (and

Re: Custom user models don't like non integer primary keys.

Hi Eric, Although the full stack trace would confirm it, I think I can guess what the problem is here -- it's the mechanism for generating reset tokens. If you dig into the token generation (and reversal) mechanisms, they use int_to_base36 and base36_to_int to convert the user's primary key into

Re: Custom user models don't like non integer primary keys.

Hey Eric -- Can you post the full traceback instead of just the snippet? Without that it's not clear whether this is a bug or just a consequence of defining your own custom user model. As the documentation notes: """ As you may expect, built-in Django's forms and views make certain assumptions

Custom user models don't like non integer primary keys.

I've been playing with custom user models. Something i've found is that trying to use the django-extensions uuidfield as a primary key doesn't seem very usable at the moment. Many of the built in auth views, specifically password reset, assume an integer field here.