Re: Changing User model

Hey, since I've got this working, I was going to explain it.

BUT, in teh intervening period, http://django-userena.org/ was bought
to my attention - I will read that coe first and potentially use.

cheers
L.



On 19 March 2013 12:29, Lachlan Musicman <datakid@gmail.com> wrote:
> On 18 March 2013 22:59, Sanjay Bhangar <sanjaybhangar@gmail.com> wrote:
>> Hey L,
>>
>> On Mon, Mar 18, 2013 at 9:13 AM, Lachlan Musicman <datakid@gmail.com> wrote:
>>> Hola,
>>>
>>> For a new project, I will be creating a separate Profile class for all
>>> information about my Users that isn't covered by User.
>>>
>>> One thing I did want though, was to change the login username to the
>>> email address.
>>>
>>> From what I've read in the code and docs, am I right in presuming that
>>> I can subclass AbstractUser and just change
>>> USERNAME_FIELD = 'email'
>>> to get this result?
>>
>> That seemed to work, yes. The problem I had, though, was once I made
>
> Ok, it doesn't work.
>
> Because there is a need to redefine email - it needs to be unique=True
> and db_index=True, there's a clash with the underlying AbstractUser
> class.
>
> So, the options are now to add a second email field to the
> AbstractUser class, or to subclass the AbstractBaseUser class.
>
> The first option is easier and is less confusing code, although it
> does have the distinctly unattractive email2 (or whatever) rather than
> email as the index and USERNAME_FIELD.
>
> The second option is annoying (cut and paste AbstractUser from
> django.contrib.auth.models but fix email), but also seems like the
> correct solution.
>
> Gah. I bite the bullet and do option 2 at this stage.
>
> cheers
> L.
>
>
>
>> this change, adding users in the default admin became totally broken,
>> and I did not find a way to fix that easily. Please do let know if you
>> manage to do this in a way that doesn't break the admin functionality
>> to add users (if you don't get care about Admin to manage users, this
>> should work no problem .. ).
>
> --
> The new creativity is pointing, not making. Likewise, in the future,
> the best writers will be the best information managers.
>
> http://www.theawl.com/2013/02/an-interview-with-avant-garde-poet-kenneth-goldsmith



--
The new creativity is pointing, not making. Likewise, in the future,
the best writers will be the best information managers.

http://www.theawl.com/2013/02/an-interview-with-avant-garde-poet-kenneth-goldsmith

On 19 March 2013 12:29, Lachlan Musicman <datakid@gmail.com> wrote:
> On 18 March 2013 22:59, Sanjay Bhangar <sanjaybhangar@gmail.com> wrote:
>> Hey L,
>>
>> On Mon, Mar 18, 2013 at 9:13 AM, Lachlan Musicman <datakid@gmail.com> wrote:
>>> Hola,
>>>
>>> For a new project, I will be creating a separate Profile class for all
>>> information about my Users that isn't covered by User.
>>>
>>> One thing I did want though, was to change the login username to the
>>> email address.
>>>
>>> From what I've read in the code and docs, am I right in presuming that
>>> I can subclass AbstractUser and just change
>>> USERNAME_FIELD = 'email'
>>> to get this result?
>>
>> That seemed to work, yes. The problem I had, though, was once I made
>
> Ok, it doesn't work.
>
> Because there is a need to redefine email - it needs to be unique=True
> and db_index=True, there's a clash with the underlying AbstractUser
> class.
>
> So, the options are now to add a second email field to the
> AbstractUser class, or to subclass the AbstractBaseUser class.
>
> The first option is easier and is less confusing code, although it
> does have the distinctly unattractive email2 (or whatever) rather than
> email as the index and USERNAME_FIELD.
>
> The second option is annoying (cut and paste AbstractUser from
> django.contrib.auth.models but fix email), but also seems like the
> correct solution.
>
> Gah. I bite the bullet and do option 2 at this stage.
>
> cheers
> L.
>
>
>
>> this change, adding users in the default admin became totally broken,
>> and I did not find a way to fix that easily. Please do let know if you
>> manage to do this in a way that doesn't break the admin functionality
>> to add users (if you don't get care about Admin to manage users, this
>> should work no problem .. ).
>
> --
> The new creativity is pointing, not making. Likewise, in the future,
> the best writers will be the best information managers.
>
> http://www.theawl.com/2013/02/an-interview-with-avant-garde-poet-kenneth-goldsmith



--
The new creativity is pointing, not making. Likewise, in the future,
the best writers will be the best information managers.

http://www.theawl.com/2013/02/an-interview-with-avant-garde-poet-kenneth-goldsmith

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.