Re: #20824 - Email-based auth contrib module; some help required

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

Re: GSoC 2014 proposal [Improving error reporting]

Hi Anubhav, Please keep in mind that this is a global mailing list, and if you want considered feedback, it's going to take time. Posting two "Please give me feedback" pings in 6 hours isn't especially helpful. There will be people who have been asleep for that entire period. Yours, Russ Magee

Re: GSoC 2014 proposal [Improving error reporting]

Please give me any reviews and suggestions regarding the issues, as and when I am posting about them. So that when I my studying and analysis of the issues is done, then I can chalk out a proper timeline for the required work as well. Regards, Anubhav Joshi IIT Patna -- You received this

Re: [gsoc] Set free the Meta.

On Thu, Feb 27, 2014 at 7:04 AM, Nikolay Baluk wrote: > > Hi, I'm Nick and I don't want to feel myself when I call obj._meta as if I > am committing a mortal sin. > > > I thought that refactoring Meta objects and make it usable is a promising > contribution for the

Re: #20824 - Email-based auth contrib module; some help required

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

Re: #20824 - Email-based auth contrib module; some help required

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

Re: #20824 - Email-based auth contrib module; some help required

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

Re: allow list_display in admin to traverse onetoonfields and foreign key relations

Hi Wim, On Wed, Feb 26, 2014 at 7:48 AM, Wim Feijen wrote: > Hello, > > Right now I have a School model containing a OneToOne-relation to User. > > In the admin, in search_fields, I can use double underscores to search in > related fields, for example: > search_fields =

Re: GSoC 2014 proposal [Improving error reporting]

Please have a look at all the issues mentioned, correct me where I am wrong and there are places where I need help(I have mentioned in those places.) I need feedback and reviews. Will be posting back again very soon with further analysis of other issues. Regards, Anubhav Joshi IIT Patna --

Re: GSoC 2014 proposal [Improving error reporting]

Here is some more analysis: django.db 1.) There is a problem with ForeignKey, which when given only blank=True causes ValidationError as they do not allow null values. If blank=True, null=True is specified then, there is no problem. The operation of ModelForms is such so as to construct

Re: Django Project Proposal

On Tuesday, February 25, 2014 10:22:02 PM UTC-8, Kevin Sebastian wrote: > > My name is Kevin Sebastian and I have been working with django for quite > some time and I would like to contribute to any of its projects.I will be > grateful if someone can offer any suggestion for the same.I am also

Re: #20824 - Email-based auth contrib module; some help required

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

Re: #20824 - Email-based auth contrib module; some help required

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

Django Project Proposal

My name is Kevin Sebastian and I have been working with django for quite some time and I would like to contribute to any of its projects.I will be grateful if someone can offer any suggestion for the same.I am also proficient in python and its various libraries and I have worked on python

Re: allow list_display in admin to traverse onetoonfields and foreign key relations

Personally I usually use lambda's, which saves another line of code: class ChoiceAdmin(admin.ModelAdmin): question__text = lambda s, o: o.question.text list_display = ('pk', 'question__text', 'choice_text', 'votes') On Wednesday, February 26, 2014 6:49:51 AM UTC+1, Zach Borboa wrote: >

Re: #20824 - Email-based auth contrib module; some help required

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:

Re: #20824 - Email-based auth contrib module; some help required

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