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 local part of the address. Most if not all final MTAs treat email addresses as case insensitive, e.g. User.Name@... ist handled the same way as user.name@..., and some users might not take care or notice of which form they used during registration. A common recommendation is to preserve but subsequently ignore case. I am handling this by using iexact lookups for users: def get_by_natural_key(self, username): return self.get(email__iexact=username) In the database, uniqueness is enforced by an expression index: CREATE UNIQUE INDEX app_user_email_key ON app_user (upper(email)) I am not sure if DBMSs other than PostgreSQL support expression indexes; either way, there is not Django support (yet). I don't know if this is of only theoretical concern, or a real world issue - maybe others using email based users could share their experience (my project is not deployed yet). Kind regards, Til -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1393407593.6478.21.camel%40mother.subnetz.org. For more options, visit https://groups.google.com/groups/opt_out.
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: stefan.joos...@gmail.com to log in. (not using his actual name) In addition, we would need a proper form error when we try to create a user having a case-insensitive duplicate e-mail. Wim On Wednesday, 26 February 2014 09:39:53 UTC, Tilman Koschnick wrote: > > 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 local part of the address. > > Most if not all final MTAs treat email addresses as case insensitive, > e.g. User.Name@... ist handled the same way as user.name@..., and some > users might not take care or notice of which form they used during > registration. A common recommendation is to preserve but subsequently > ignore case. > > I am handling this by using iexact lookups for users: > > def get_by_natural_key(self, username): > return self.get(email__iexact=username) > > In the database, uniqueness is enforced by an expression index: > > CREATE UNIQUE INDEX app_user_email_key ON app_user (upper(email)) > > I am not sure if DBMSs other than PostgreSQL support expression indexes; > either way, there is not Django support (yet). > > I don't know if this is of only theoretical concern, or a real world > issue - maybe others using email based users could share their > experience (my project is not deployed yet). > > Kind regards, Til > > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/fab46e55-7dad-4d7d-be55-ea13b606431d%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
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:
>
> I agree that the current behaviour is confusing and needs change in order
> to be DRY[1] and consistent[2].
>
> [1]
> https://docs.djangoproject.com/en/dev/misc/design-philosophies/#don-t-repeat-yourself-dry
> [2]
> https://docs.djangoproject.com/en/dev/misc/design-philosophies/#consistency
>
>
>
> This is how I currently work around this issue.
>
> models.py
> class Question(models.Model):
> text = models.CharField(max_length=200)
> pub_date = models.DateTimeField('date published')
>
> class Choice(models.Model):
> question = models.ForeignKey(Question)
> choice_text = models.CharField(max_length=200)
> votes = models.IntegerField(default=0)
>
> admin.py
> class ChoiceAdmin(admin.ModelAdmin):
> def question__text(self, obj):
> return obj.question.text
>
> list_display = ('pk', 'question__text', 'choice_text', 'votes')
>
> admin.site.register(Choice, ChoiceAdmin)
>
>
>
>
>
>
> On Tuesday, February 25, 2014 3:48:40 PM UTC-8, 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 = ('place__name', 'school__name')
>>
>> But in list_display, I can't. For example,
>> list_display = ['school', 'school__user', 'place', ]
>> gives an error.
>>
>> I find this totally confusing. More people do.
>>
>> A ticket has been made six years ago and was eventually closed as won't
>> fix. Currently, the proposed solution is to write a custom method or
>> callable. I'd like to raise a discussion to reopen that ticket.
>>
>> For reference, see:
>> https://code.djangoproject.com/ticket/5863
>> https://groups.google.com/forum/#!topic/django-developers/eQSEv74bQh8
>>
>> My arguments to allow such a syntax are:
>>
>> 1. allowing 'school__user' in list_display is consistent with the
>> behaviour of search_fields, list_filter in the admin, and get() and
>> filter() query syntax in general.
>> 2. it saves many people duplicating two to four lines of custom code, and
>> in my opinion, allows for a more concise yet extremely easy to understand
>> notation.
>> 3. ideally, a solution would use select_related in order to save database
>> queries and thus be longer than two to four lines of code.
>> 4. the need is common, and in onetoonefields specifically. Many people
>> have expressed their interest in this feature, and a core developer
>> initially accepted it.
>> 5. a long time has passed since then and our policy of accepting tickets
>> has changed.
>>
>> Thanks for reading! I'd love to hear your response.
>>
>> Regards, Wim
>>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/96177bfe-e83a-4b35-9bab-0ff8fe3b3839%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
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 applications before. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d4c8f87f-1684-4402-8373-18a0adfc52bf%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
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 created the FK references are set. The only solution I found was to use tox (which I was already using to test versus multiple Python/Django versions) and run the full suite once with the standard user model and again with a custom user model. Some tests are skipped when the default user is used and others are skipped with the custom user is in use. You can see it in action here: https://github.com/mlavin/django-all-access I'd love to see a more general solution to this but I have a feeling anything that attempts to modify the DB tables between tests is destined to fail. Best, Mark On Wednesday, February 26, 2014 2:33:24 AM UTC-5, Russell Keith-Magee wrote: > > Hi all, > > tl;dr; I've been working on a last little feature for 1.7 - an email-based > User model for contrib, but I need some help/guidance on the last step - > getting the tests working. > > The idea here is that we just ship a normal auth.User, but with email > identification rather than username. This is essentially the 80% case for > requests for custom User models anyway, and it provides an example of "how > to do it" for anyone that wants to follow the lead. > > I've also taken the opportunity to do a bit of refactoring of auth forms > and the AbstractUser to make re-use of common parts a bit easier. > > Code is available here. Other than bikeshed stuff (name of module, name of > classes etc) it shouldn't be too controversial: > > https://github.com/freakboy3742/django/tree/emailauth > > There are two things still pending on this patch: > > 1) Documentation. There isn't much to document, but obviously this is > required. > > 2) Tests that work. > > It's the second point where I need some assistance (or at the very least, > some suggestions of directions I can go with this). > > There isn't that much that requires testing -- after all, it's a fairly > vanilla User model. A bit of light testing of forms, some checks to make > sure that the models can be created, and that they play well with > ModelBackend, and so on. > > However, there's a problem with including these tests as part of Django's > own testing infrastructure, due to clashes with Django's default User model. > > In a production app, you either want a normal Django User model, in which > case you don't include contrib.emailauth in your app; or you include > contrib.emailauth, and you set AUTH_USER_MODEL must be set (I haven't added > a formal check for this, but I could). As a result, there's no confusion > over which User model is active. I've done some manual testing, and the > user model all works as expected. > > While running Django's test suite, however, the suite installs both > contrib.auth and contrib.emailauth, but *doesn't* set AUTH_USER_MODEL to > emailauth -- it can't, because we need to test default User behaviours. > > Both auth.User and emailauth.User have relations with Group, and the names > clash, so the test suite won't start. > > If you deliberately silence the model integrity system checks, you get > other errors, caused by the fact that there's confusion over which > AUTH_USER_MODEL is active at any given time. > > So - I'm looking for suggestions for how this can be handled in Django's > test suite. > > I've thought about explicitly excluding contrib.emailauth from the test > suite's INSTALLED_APPS, but then the tests in emailauth don't get > discovered and executed. > > Even if you reorganise the tests to make them part of the "django" tests, > rather than tests that are part of the contrib app, you get problems > because you end up with two models with the same relation name to Group. > > So - anyone got any ideas how to handle this? Is there some feature of the > new app loading code that I can exploit here? > > Yours, > Russ Magee %-) > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a3259799-00a4-432c-ab59-d0401c44625e%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
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 app cache. That feature would have solved your problem. It was implemented by removing models modules from sys.modules and re-importing them. Since imports can have side effects in Python, and considering the amount of pain duplicate imports have caused before Carl fixed the projet layout, I didn't want to reimport modules. I wasn't comfortable with hacking sys.modules either because smart hacks tend to backfire. I've been thinking about creating a copy of auth.Group tied to EmailUser -- which would just mean executing of copy of the definition of the Group model while AUTH_USER_MODEL points to EmailUser -- and injecting it into the app registry by abusing private APIs. But that would require a copy of auth.Permission and any related model, recursively, which is impractical. You could hack into auth.Group internals to remove and recreate its relations, but that's hardly setting a good precedent. The current implementation of the ORM assumes that your models don't change at runtime and I'm not sure you can work around that sustainably. -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CANE-7mUvJqEkQ_Oe2DTxU_Wt_ZqdVA4iOSXg4NxaqbowOVe0Qw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
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 > proficient in python and its various libraries and I have worked on python > applications before. > Check out the documentation on the Django project site, specifically this page. It gives you information on how to contribute and how to get started. https://docs.djangoproject.com/en/1.6/internals/contributing/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/b93a1317-118b-4a14-9ea1-5912cadc5176%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
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 instances at validation time, not at save-time, Null and wrong-model assignments to ForeignKey fields are disallowed prior to save-time. Therefore, there is problem when we try to call is_valid() or save(). Currently if blank=True and null is not True, ValueError is raised. The check being in related.py #399 for ForeignKey. a.) I think we can display a correct message depicting the problem that in ForeignKey with null=True can only be left blank. b.) We can stop the usage of blank=True with ForeignKey, because alone without null=True defined it has no significance and give suitable error message instead of raising an error. null=True alone works perfectly Related: #13776 2.) Unpickling Models and QuerySet from incompatible version. A patch was submitted in regard for this, but it breaks the tests. So, some work needs to be done to fix that.Probably it s because of some fault in django/utils/version.py as far as I have apprehended. Also 'akaariai on github' suggested that we can think of extending this behaviour to do cross-version conversions in case of model unpickling. Upon doing some study and having a discussion on irc with 'apollo13', I have understood how the pickling works and what protocol does django uses. Further I have understood that to do the required, we would need to convert internal data-structures between versions. This could be achived by first finding out the version of the current installation and pickled data. We can store the differences in _meta for models for different versions in a separate file e.g pickle_ver.py. Then accordingly we can define __setstate__() on its basis. We can create a new model instance from the unpickled data, using pickle_ver.py, and then use its state for __dict__. Related: #21430 3.) In certain situations with PostgreSQL, a bogus error message about SET TIME ZONE may be returned. See #3179 (which is closed, but has a description of the problem). The real error message can probably be found in the postgres log file. Till now I have only understood what the problem is. I would need some guidance here, coz I have no knowledge of PostgreSQL as of now. I myself am also trying to consult someone whom I know for this. Although as mentioned for the shell part, we can do the same for views also, we need to figure out how to catch that previous error(due to which we get this behaviour) and then perform cursor rollback with appropriate warning. 4.) #10811 I had written a patch for this but it got stuck at a place leading to failure of two tests. I didn't got the time to look into it much then, I will do that and sort this out. https://github.com/django/django/pull/2162 5.) There has been strange errors being reported because of lack of date[time] CAST conversions in backends. This has been extensively discussed in #7074. Only Oracle implements this correctly. A sample workaround as suggested in the ticket: django/db/models/sql/where.py in make_atom def datetime_cast_sql(self): return 'CAST(%s AS DATETIME)' def rhs_cast_sql(self, db_type): if db_type in ['date', 'datetime']: return 'CAST(%%s AS %s)' % db_type return '%s' In where.py make_atom if value_annot is datetime.datetime: cast_sql = connection.ops.datetime_cast_sql() else cast_sql = connection.ops.rhs_cast_sql(db_type) But the thing is that, we are putting the fix in two different places. What is required here is a single general right hand casting hook so that when values when are passed as strings instead of datetime.datetime objects then we can CAST them appropriately for different backends. For this I am not sure whether this CASTING should be done only for date[time] objects or it might be required in some other cases as well. I need some review here. Only then can I proceed towards writing that single casting function. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/deee2141-9db2-468b-9567-1dc9ca34d963%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
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 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0f809b68-90d5-43d0-a792-ace05f97ffb0%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
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 = ('place__name', 'school__name')
>
> But in list_display, I can't. For example,
> list_display = ['school', 'school__user', 'place', ]
> gives an error.
>
> I find this totally confusing. More people do.
>
> A ticket has been made six years ago and was eventually closed as won't
> fix. Currently, the proposed solution is to write a custom method or
> callable. I'd like to raise a discussion to reopen that ticket.
>
> For reference, see:
> https://code.djangoproject.com/ticket/5863
> https://groups.google.com/forum/#!topic/django-developers/eQSEv74bQh8
>
> My arguments to allow such a syntax are:
>
> 1. allowing 'school__user' in list_display is consistent with the
> behaviour of search_fields, list_filter in the admin, and get() and
> filter() query syntax in general.
>
Arguable. As Luke points out in his post to django-dev, the list_display
serves a different purpose to search_fields and list_filter. The latter are
direct database analogs; the former is a display directive. I agree that
consistency is a good thing (I'll even admit that I've inadvertantly put
foo__bar in list_display definitions when I wasn't thinking clearly), but
as Luke points out, the answer isn't *quite* as simple as "just be
consistent", because list_display needs to support modes of interaction
that search_fields and list_filter doesn't.
There's also an argument to be made that in order to achieve "consistency",
support for dunder syntax should be taken *out* of search_fields and
list_filter, to be replaced by richer mechanisms, along the line of custom
filter objects.
2. it saves many people duplicating two to four lines of custom code, and
> in my opinion, allows for a more concise yet extremely easy to understand
> notation.
>
The counterargument to this is that Django should provide a shortcut
function to make it easy. Luke even provides a sample implementation on the
ticket; if we put this in contrib.admin, your "lines of code" argument
would be void.
> 3. ideally, a solution would use select_related in order to save database
> queries and thus be longer than two to four lines of code.
>
I'm a little wary about code being too smart, but yes, there's an
opportunity for optimisation here.
> 4. the need is common, and in onetoonefields specifically.
>
I haven't seen any evidence to support this claim. *You* definitely
need/want it, and there are a handful of participants on the ticket that
clearly want it - but Admin hasn't had this behaviour since the
beginning, and this is the first time in 3 years that the issue has been
raised on the mailing list. We haven't been flooded with requests for this
feature.
> Many people have expressed their interest in this feature, and a core
> developer initially accepted it.
>
True - but many more subsequently rejected it, and have provided detailed
arguments why.
> 5. a long time has passed since then and our policy of accepting tickets
> has changed.
>
Erm... it has? That's news to me.
I'm certainly sympathetic to your request. As I said - I've even made the
mistake of assuming this feature exists. However, Luke makes some very
valid points in his post that you haven't addressed.
The two biggest practical issues he raises:
* Differentiating between '__unicode__' and 'foo__bar'
* The appropriate default column name for 'foo__bar'
If you've got reponses to these issues, please make them, otherwise, I'm
inclined to stick with Luke's analysis. However, I'm a weak -0; I could
live with the pragmatic argument that it's more confusing to not have this
feature, even though the column naming will likely be weird.
I *would* however, be in favour of adding a shortcut along the lines of the
one Luke provided in the ticket.
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAJxq84-pfaj079spYahCej-FuiH5aciA7t3dXZ1Y_L344GZzcw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
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 like the only option that would be available to us. We could go the extra step to cleanse data on the way into the database (e.g., forcing lowercase on save) but we can't guarantee that data isn't finding it's way into the user table from other sources, so we shouldn't rely on the fact that the database contains a "known to be in lower case" representation. Yours, Russ Magee %-) On Wed, Feb 26, 2014 at 9:06 PM, Wim Feijen wrote: > 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.joos...@gmail.com to log in. (not using his actual name) > > In addition, we would need a proper form error when we try to create a > user having a case-insensitive duplicate e-mail. > > Wim > > > On Wednesday, 26 February 2014 09:39:53 UTC, Tilman Koschnick wrote: >> >> 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 local part of the address. >> >> Most if not all final MTAs treat email addresses as case insensitive, >> e.g. User.Name@... ist handled the same way as user.name@..., and some >> users might not take care or notice of which form they used during >> registration. A common recommendation is to preserve but subsequently >> ignore case. >> >> I am handling this by using iexact lookups for users: >> >> def get_by_natural_key(self, username): >> return self.get(email__iexact=username) >> >> In the database, uniqueness is enforced by an expression index: >> >> CREATE UNIQUE INDEX app_user_email_key ON app_user (upper(email)) >> >> I am not sure if DBMSs other than PostgreSQL support expression indexes; >> either way, there is not Django support (yet). >> >> I don't know if this is of only theoretical concern, or a real world >> issue - maybe others using email based users could share their >> experience (my project is not deployed yet). >> >> Kind regards, Til >> >> >> -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/fab46e55-7dad-4d7d-be55-ea13b606431d%40googlegroups.com > . > > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq84_b5eRzyCAp5erYvKir98ZRrpM80pxWLTiMOWgScxnRFw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: #20824 - Email-based auth contrib module; some help required
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 recently with a client. They opted for all lower case but only because of legacy data.] -- Curtis On 27 February 2014 11:11, Russell Keith-Magee wrote: > > 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 like the only option that would be available > to us. We could go the extra step to cleanse data on the way into the > database (e.g., forcing lowercase on save) but we can't guarantee that data > isn't finding it's way into the user table from other sources, so we > shouldn't rely on the fact that the database contains a "known to be in > lower case" representation. > > Yours, > Russ Magee %-) > > On Wed, Feb 26, 2014 at 9:06 PM, Wim Feijen wrote: > >> 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.joos...@gmail.com to log in. (not using his actual name) >> >> In addition, we would need a proper form error when we try to create a >> user having a case-insensitive duplicate e-mail. >> >> Wim >> >> >> On Wednesday, 26 February 2014 09:39:53 UTC, Tilman Koschnick wrote: >>> >>> 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 local part of the address. >>> >>> Most if not all final MTAs treat email addresses as case insensitive, >>> e.g. User.Name@... ist handled the same way as user.name@..., and some >>> users might not take care or notice of which form they used during >>> registration. A common recommendation is to preserve but subsequently >>> ignore case. >>> >>> I am handling this by using iexact lookups for users: >>> >>> def get_by_natural_key(self, username): >>> return self.get(email__iexact=username) >>> >>> In the database, uniqueness is enforced by an expression index: >>> >>> CREATE UNIQUE INDEX app_user_email_key ON app_user (upper(email)) >>> >>> I am not sure if DBMSs other than PostgreSQL support expression indexes; >>> either way, there is not Django support (yet). >>> >>> I don't know if this is of only theoretical concern, or a real world >>> issue - maybe others using email based users could share their >>> experience (my project is not deployed yet). >>> >>> Kind regards, Til >>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-developers+unsubscr...@googlegroups.com. >> To post to this group, send email to django-developers@googlegroups.com. >> Visit this group at http://groups.google.com/group/django-developers. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/fab46e55-7dad-4d7d-be55-ea13b606431d%40googlegroups.com >> . >> >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAJxq84_b5eRzyCAp5erYvKir98ZRrpM80pxWLTiMOWgScxnRFw%40mail.gmail.com > . > > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAG_XiSDAYHzQfw%2BBr_roy%3D6%2Bjx1TN94gNvbhjXnPZZ_UCMJFDA%40mail.gmail.com. For more opt
[gsoc] Set free the Meta.
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 community, because there are a lot of situation when accessing _meta attributes and methods can save a lot of developers time: you can find hundreds real-life examples on Stackoverflow.com where people use _meta, but make a remark that it’s private, not recommended to use in general and should be covered with unit tests (yeah, that’s great, but not when you had to cover framework’s code). It also may be useful for those who chose to encapsulate their business logic in a “fat” models instead of views (can't imagine such use case of meta right now) since I think it’s a really good way to architect Django’s apps. As for me, I’m currently using Django-nonrel and, for example, I had to survive without multi table inheritance, so I really need to know many information about model classes and instances that is available but like forbidden fruit. It’s time to change that! :) Many of those for whom the Django is made are think: if it is written in the documentation -- then it can and should be used. If not -- don't even touch this. That’s the first reason why documenting Meta is the most responsible task. Second is that documentation (and the api itself, of course) should warn the user against destructive use of the object's interior. So, I’m as non-native English speaker, may seem at first glance not the best candidate for this, but I will put a lot of effort to find the best person for review of what I will write and the Django’s docs writing style looks very laconic. I am a little scared to work under hood of Django, but more challenging -- is more interesting. Any help with this project would be greatly appreciated! *Brief plan:* 1. Learn what actually supposed to be opened. I mean we have a few options. We can make stable and expose the whole obj._meta; we can make stable obj._meta, document it as well, but point some things which are really necessary for developers to obj.meta since it’s sound more comfortable to use and bonus points for backwards compatibility if any issues will appear. 2. Have fun while exploring Django so deeply (Options class and other meta related code). 3. Clean up related classes. 4. Write some unit tests that supposed to be self-documented my point of view on how API should looks like consequently. Ask Russell Keith-Magee (as my mentor) for master class about how API actually should looks like. 5. Do what developers usually do. Write brilliant clean code. 6. Cover all that with docs and examples. 7. Make sure that all is meets the requirements of Django standards. *A bit about myself:* Born and still in Ukraine. 21 years old. Last 5 years of my life I’m busy doing cool and not cool stuff using my programming skills (a couple of years in Django). In 2012 I've founded a Google Developer Group (GDG) community in my city, so sometimes we hold different events for developers. It would be really great if we could hold a Django thematic event with help of Django community! By the way, I am happy to help students in this mail-list by answering questions as a student that are previously participated in gsoc. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a74a02fe-ce13-413c-b10b-7bd0ebcb40b3%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
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 the docs it's used so if you want to change it, that's the hook. > 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 database that might exist. So - while normalising case is probably a good idea, and should probably be added to the Create/Update User form, the searches will still need to be case insensitive. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq84_1%2B_oVDUAeHyXoFGTirsZEgejaY6q4hNK0EZGpqS96Wg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
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 transformation and then perform an *exact* search after applying the same transformation to the input? One idea could be to add a 'transform_email' or similar hook that by default calls normalize_email and ensure that it is applied both to data that is about to be saved and to search terms. Projects that wish to change the behaviour can simply override transform_email to perform for example lowercase conversion if so desired. Atul On 27 February 2014 11:43, Russell Keith-Magee wrote: > > On Thu, Feb 27, 2014 at 8:31 AM, Curtis Maloney < > cur...@acommoncreative.com> 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 want to change it, that's the hook. >> > > 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 > database that might exist. > > So - while normalising case is probably a good idea, and should probably > be added to the Create/Update User form, the searches will still need to be > case insensitive. > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAJxq84_1%2B_oVDUAeHyXoFGTirsZEgejaY6q4hNK0EZGpqS96Wg%40mail.gmail.com > . > > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAHdnYzuJw_g2ZmzoQ%2B51v5BC1FcD0wN4TgazFoJgT1ZVEYDOWA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
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 community, because there are a lot of situation when > accessing _meta attributes and methods can save a lot of developers time: > you can find hundreds real-life examples on Stackoverflow.com where people > use _meta, but make a remark that it's private, not recommended to use in > general and should be covered with unit tests (yeah, that's great, but not > when you had to cover framework's code). It also may be useful for those > who chose to encapsulate their business logic in a "fat" models instead of > views (can't imagine such use case of meta right now) since I think it's a > really good way to architect Django's apps. > > As for me, I'm currently using Django-nonrel and, for example, I had to > survive without multi table inheritance, so I really need to know many > information about model classes and instances that is available but like > forbidden fruit. It's time to change that! :) > > > Many of those for whom the Django is made are think: if it is written in > the documentation -- then it can and should be used. If not -- don't even > touch this. That's the first reason why documenting Meta is the most > responsible task. Second is that documentation (and the api itself, of > course) should warn the user against destructive use of the object's > interior. > > So, I'm as non-native English speaker, may seem at first glance not the > best candidate for this, but I will put a lot of effort to find the best > person for review of what I will write and the Django's docs writing style > looks very laconic. > > I am a little scared to work under hood of Django, but more challenging -- > is more interesting. > Any help with this project would be greatly appreciated! > > > *Brief plan:* > > > 1. Learn what actually supposed to be opened. > I mean we have a few options. We can make stable and expose the whole > obj._meta; we can make stable obj._meta, document it as well, but point > some things which are really necessary for developers to obj.meta since > it's sound more comfortable to use and bonus points for backwards > compatibility if any issues will appear. > > 2. Have fun while exploring Django so deeply (Options class and other meta > related code). > > 3. Clean up related classes. > > 4. Write some unit tests that supposed to be self-documented my point of > view on how API should looks like consequently. Ask Russell Keith-Magee (as > my mentor) for master class about how API actually should looks like. > > 5. Do what developers usually do. Write brilliant clean code. > > 6. Cover all that with docs and examples. > > 7. Make sure that all is meets the requirements of Django standards. > Hi Nikolay Glad to see you're interested in hitting a difficult problem like cleaning up Meta! It sounds like you've got the broad idea of what is required for this project; however, a successful project application will need a little more detail than this. Specifically, we're looking for a timeline (in blocks of about a week, and no more than 2 weeks) detailing what you're going to do over the 12 week program. We ask for this for two reasons: Firstly, in order to provide a detailed timeline, you need to fully understand the problem. It's not enough to just say "6 weeks: Fix the problems; 6 weeks: document the result". We're looking for a detailed teardown of specific activities. In order to provide this sort of timeline, you need to study the problem enough to identify specific coding/refactoring activities. Secondly, it gives us a mechanism to measure your progress. If, after 3 weeks, you still haven't finished the work allocated for week 1, we can guess you're not going to finish. However, if you've finished 6 weeks of work in 3 weeks, we know we'll need to find something else to fill your summer :-) Since this is a refactoring and documentation project, I'd also suggest that it might be helpful to have an independent way of evaluating success. Since you're experienced with Django-nonrel, this provides a potentially interesting option. One of the reasons for documenting Meta is to guarantee the interface it provides. The Meta interface exists to allow introspection, which is then used by ModelForms and Admin to provide automated (or semi-automated) interfaces. So - as a proof of concept that your refactoring works, you might commit to producing a wrapper for django-nonrel (or, to keep it simpler - a single nonrel data store) that is sufficiently "Meta-compliant" that it can be displayed in admin, and be displayed/edited in a ModelForm. To be clear - this isn't about adding Nonrel support to Django's core -- it's about proving that as a result of your refactor and documentation, Django provides the tools to allow external tools to interac
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 message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1ca9ce43-5b59-4601-b6d2-5be43b28d740%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
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 %-) On Thu, Feb 27, 2014 at 11:08 AM, anubhav joshi wrote: > 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 message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/1ca9ce43-5b59-4601-b6d2-5be43b28d740%40googlegroups.com > . > > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq84-y%3D4PZ3qYwH6XAaeDtzh_bxru9xDGS45pK0xEy4uBtWg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
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 my humble sacrifice. ;) 1. Create extra model unique field containing lowercase email or some hash of it - this looks very hacky thing to do that would give plenty of people "ahaaa!" moment when they run into problems... and they won't be pleased aftherwards. 2. Add ci_unique option to the ORM fields - this will need changes in the ORM's and migrations implementation, plus note in docs that it won't fly on certain DB's and other means would be used. 3. Add "case_sensitive=True" kwarg to create_unique for use in migrations that would make created unique constraint case insensitive. Then, add note to the user auth doc's about gotcha with case sensitivity and provide extra documentation with examples for solving this problem via that function and custom migrations. My favorite because it appears to be least invasive towards existing codebase, may be reauseable for other custom use-aces, but may be considered secret knowledge by people only just beginning with Django if not presented correctly in docs. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/e28e8809-3d42-4f1a-b288-e6e3bc832552%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
