Hi JJ,
On Mon, Sep 8, 2014 at 2:26 AM, JJ Zolper wrote:
> Hey guys,
>
> I can only imagine how busy everyone has been with Django 1.7 and getting
> that wrapped up with all the great new features it includes. I know I have
> been spending a good bit of time updating my work.
>
> I know Russell s
Hey guys,
I can only imagine how busy everyone has been with Django 1.7 and getting
that wrapped up with all the great new features it includes. I know I have
been spending a good bit of time updating my work.
I know Russell said here that we were thinking it could be put out in 1.7
but I tota
The following may be a viable solution for the case-insensitive fields.
(email, username, alias ... etc.)
Look at lines: 23, 66 and 159.
https://gist.github.com/un33k/9273782
Val
On Fri, Feb 28, 2014 at 5:05 AM, Tilman Koschnick wrote:
> On Thu, 2014-02-27 at 08:43 +0800, Russell Keith-Mag
On Thu, 2014-02-27 at 08:43 +0800, Russell Keith-Magee wrote:
> It does - assuming you use User.objects.create_user() to create all
> your users. However, the UserCreationForm doesn't use this (and hasn't
> ever used this); it also doesn't account for fixtures, or any other
> path into the databas
On Thu, 2014-02-27 at 20:11 -0800, schinckel wrote:
> But there's the rub. Whilst for _most_ email servers, this will indeed
> send mail to the same account, there's nowhere that says this _must_
> happen.
I agree. Reading RFC 822, it says
The domain-dependent
string is
On Friday, February 28, 2014 12:55:31 PM UTC+10:30, waylan wrote:
>
> On Thursday, February 27, 2014 6:50:38 PM UTC-5, Camilo Torres wrote:
>>
>> normalize_email will indeed allow both us...@example.com and
>> us...@example.com to be different entities. From the user perspective,
>> this is an
On Thursday, February 27, 2014 6:50:38 PM UTC-5, Camilo Torres wrote:
>
> normalize_email will indeed allow both us...@example.com and
> us...@example.com to be different entities. From the user
> perspective, this is an error. Most probably the user enters some day their
> email in all upper c
normalize_email will indeed allow both u...@example.com and
u...@example.com to be different entities. From the user perspective, this
is an error. Most probably the user enters some day their email in all
upper case because he pressed the CapsLock key, or copy pasted a transcript
of his email,
I've got plenty ideas for approaching issue of enforcing case insensitive
uniqueness of email on DB level while still maintaining original case of
name part. They differ in level of hackiness or amount of change needed,
but if somebody has to make fool of himself proposing them, please accept
m
Won't normalize_email will allow two distinct users u...@example.com and
u...@example.com to be created? Case insensitive searches will return
multiple users for a 'get'.
Perhaps the closest we can get is to ensure that any user created using
Django functions is saved with a consistent case transf
On Thu, Feb 27, 2014 at 8:31 AM, Curtis Maloney
wrote:
> Doesn't the UserManager already have a "normalize_email" method which
> lower-cases the domain and leaves the mailbox name alone?
>
> IMHO It's "proper" to leave it this way by default, and probably mention
> in the docs it's used so if you
Doesn't the UserManager already have a "normalize_email" method which
lower-cases the domain and leaves the mailbox name alone?
IMHO It's "proper" to leave it this way by default, and probably mention in
the docs it's used so if you want to change it, that's the hook.
[We went through this recent
This is a good point - I hadn't fully considered the issue of case in email
addresses.
I agree that a case-insensitive index would be ideal; however, that's not
an option we have available across databases.
Wim's suggestion to do case insensitive searches in forms,
get_by_natural_key etc sounds l
2014-02-26 8:33 GMT+01:00 Russell Keith-Magee :
> Is there some feature of the new app loading code that I can exploit here?
Unfortunately not. One of the main differences between Arthur Koziel's GSoC
and what I committed is that I removed the "reload()" feature for the app
cache. That feature w
Welcome to the pain that third party app maintainers have already been
dealing with for the past year. I ran into this problem as well when I
added custom user support to one of the apps I maintain. As you noted you
can't simply change the AUTH_USER_MODEL setting because once the test DB is
cre
Hi Tilman,
Thanks for bringing this up. I lowercase my e-mail addresses every time -
and when I forget I am wading through a pile of shit. (excusez le mot)
Your solution looks neater, because it maintains user input. I have had
users who used stefan.joos...@gmail.com once and later on:
stefan.
Hi Russell,
On Wed, 2014-02-26 at 15:33 +0800, Russell Keith-Magee wrote:
> The idea here is that we just ship a normal auth.User, but with email
> identification rather than username.
I have just implemented an email based User model as well, and was
wondering about case sensitivity in the loca
17 matches
Mail list logo
