Fellow Report - July 30, 2016

[Tim Graham]

Triaged

---

https://code.djangoproject.com/ticket/26941 - Remove quotes from uwsgi "env 
= LANG=…" configuration (fixed)

https://code.djangoproject.com/ticket/26935 - DB connections stuck in 
closed state when using Django ORM in daemon (duplicate)

https://code.djangoproject.com/ticket/13978 - Allow inline js/css in 
forms.Media (wontfix)

https://code.djangoproject.com/ticket/26950 - Removed unused 
DatabaseOperations methods (created)

https://code.djangoproject.com/ticket/26958 - Django urlize inside html 
tags (invalid)

https://code.djangoproject.com/ticket/26957 - Inconsistency between doc and 
code: authenticate() when user.is_active == False (accepted)

https://code.djangoproject.com/ticket/26962 - docs: Missing Information 
about Transaction in Operations (migrations) (accepted)

https://code.djangoproject.com/ticket/26960 - Allow user login after 
password reset (accepted)

https://code.djangoproject.com/ticket/26953 - Custom manager inheriting 
BaseManager.from_queryset() crashes with AssertionError (invalid)

https://code.djangoproject.com/ticket/26954 - has_module_permission set to 
False on ModelAdmin raises 403 Forbidden error when visiting its app page 
(accepted)

https://code.djangoproject.com/ticket/26963 - Improve error message when 
trying to insert a value that overflows DecimalField (invalid)

https://code.djangoproject.com/ticket/26959 - AssertionError in query.py 
change_aliases (duplicate)

https://code.djangoproject.com/ticket/26964 - No mention of index_together 
on the GenericForeignKey section (duplicate)

https://code.djangoproject.com/ticket/26965 - Postgres Full Text Search in 
ModelAdmin.search_fields (duplicate)

https://code.djangoproject.com/ticket/26955 - Multi-db example : default 
database config can not be an empty dict (needsinfo)

https://code.djangoproject.com/ticket/26973 - i18n template tag loading 
error when setting show_indexes=True for views.static.serve (accepted)

Authored



https://github.com/django/djangopeople/compare/6ef7c9fe4987204fb063ee3cdceea5a993aae306...7753a9f3c1793852d15818ecdc33c4a6d7545d08
 
- Updated from Django 1.6 to 1.9

https://github.com/django/djangopeople/pull/69 - Update to Python 3.5.2

https://github.com/django/django/pull/6990 - Refs #25550 -- Corrected 
deprecation message for assigning M2M relations.

https://github.com/django/django/pull/6992 - Fixed #26970 -- Fixed crash 
with disabled ModelMultipleChoiceField.

https://github.com/django/django/pull/6994 - Fixed #26930 -- Prevented 
makemigrations from accessing an empty database.

Reviewed/committed

--

https://github.com/django/django/pull/6933 - Fixed #26915 -- Fixed 
regression handling responses returned from view middleware

https://github.com/django/django/pull/6927 - Fixed #26114 -- Fixed 
AlterModelTable.describe() if db_table is None.

https://github.com/django/django/pull/6944 - Fixed #26929 -- Deprecated 
extra_context parameter of contrib.auth.views.logout_then_login().

https://github.com/django/django/pull/6948 - Fixed #26657 -- Fixed MySQL 
5.7 GIS test failures.
https://github.com/django/django/pull/6989 - Fixed #26896 -- Allowed a lazy 
base_url for FileSystemStorage.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8d0b6db9-7c15-482f-8167-3ab0594aef24%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: status of 1.10 release blockers

[Tim Graham]

The final release is on schedule for Monday, August 1.

On Thursday, July 14, 2016 at 10:05:39 AM UTC-4, Markus Holtermann wrote:
>
> Thank you for the update, Tim. 
>
> #26888 will be taken care of by tomorrow. Either Marten or I are pushing 
> a PR. 
>
> Cheers, 
>
> /Markus 
>
> On Thu, Jul 14, 2016 at 06:41:51AM -0700, Tim Graham wrote: 
> >I'm planning for the release candidate on Monday. 
> > 
> >The one blocker is #26888  
> - 
> >RegexURLResolver doesn't work in threaded environments. 
> > 
> >On Tuesday, June 21, 2016 at 4:29:47 PM UTC-4, Tim Graham wrote: 
> >> 
> >> The blocker is merged so I'll release the beta in a couple hours if no 
> one 
> >> stops me. 
> >> 
> >> On Monday, June 20, 2016 at 9:10:12 PM UTC-4, Tim Graham wrote: 
> >>> 
> >>> The remaining blocker: 
> >>> 
> >>> UserCreationForm doesn't call normalize_email and normalize_username 
> >>> https://code.djangoproject.com/ticket/26719 
> >>> Status: I sent some final edits to the PR and it should be ready for 
> >>> commit tomorrow. 
> >>> 
> >>> Other possible blockers: 
> >>> 
> >>> Different manager for _base_manager and related descriptors 
> >>> https://code.djangoproject.com/ticket/26749 
> >>> django-hvad is broken by the manager inheritance refactor and it's 
> >>> unclear if it can be adapted for the new behavior. 
> >>> 
> >>> Update decorator_from_middleware() to work with DEP5 style middleware. 
> >>> https://code.djangoproject.com/ticket/26626 
> >>> Design decision needed, see 
> >>> 
> https://groups.google.com/d/topic/django-developers/hNQIaYcN3xM/discussion 
> >>> 
> >>> As long as no new issues pop up by tomorrow, I'm thinking to do the 
> beta 
> >>> release then. We might consider a "beta 2" release around 2 weeks 
> later if 
> >>> we decide to push fixes for the other two issues. 
> >>> 
> >>> On Saturday, June 18, 2016 at 8:05:32 PM UTC-4, Tim Graham wrote: 
>  
>  I'm postponing the release until next week as some release blockers 
>  remain: 
>  
>  
>  
> https://code.djangoproject.com/query?status=!closed=Release%20blocker
>  
>  
>  On Friday, June 17, 2016 at 5:33:04 PM UTC-4, Claude Paroz wrote: 
> > 
> > Le vendredi 17 juin 2016 16:52:50 UTC+2, Tim Graham a écrit : 
> >> 
> >> There are a few small issues to finish up, but if all goes well, 
> the 
> >> beta release will happen sometime tomorrow (at least 24 hours from 
> now). 
> >> 
> > 
> > I'm a bit worried about https://code.djangoproject.com/ticket/26719 
> > which could have security implications for 1.10. To be 
> investigated... 
> > 
> > Claude 
> > 
>  
> > 
> >-- 
> >You received this message because you are subscribed to the Google Groups 
> "Django developers  (Contributions to Django itself)" group. 
> >To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-develop...@googlegroups.com . 
> >To post to this group, send email to django-d...@googlegroups.com 
> . 
> >Visit this group at https://groups.google.com/group/django-developers. 
> >To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/94dd42e9-6940-4377-bd8e-7b285d0a63bc%40googlegroups.com.
>  
>
> >For more options, visit https://groups.google.com/d/optout. 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/34304173-2186-4dcb-9e0e-98a1d86c960a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extend support for long surnames in Django Auth

[Donald Stufft]

> On Jul 30, 2016, at 4:40 PM, Aymeric Augustin 
>  wrote:
> 
> I have trouble believing that a significant number of people are used to 
> typing 100+ characters when inputting their name into a website — let alone 
> that a significant number of people have a last name that contains more than 
> 100 characters and that isn’t a joke. How would it fit on a passport?


See #6 of 
https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/

—
Donald Stufft



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5DE6F3BD-2AFC-4DC2-864F-D68D333587B4%40stufft.io.
For more options, visit https://groups.google.com/d/optout.

Re: Extend support for long surnames in Django Auth

[Aymeric Augustin]

Hello,

> On 30 Jul 2016, at 10:52, Raony Guimaraes Corrêa Do Carmo Lisboa Cardenas 
>  wrote:
> 
> So I'm suggesting a change from 30 to 255 characters on last_name field, 
> which is the maximum possible without breaking backwards compatibility.

I’m -1 on basing the decision of “how long a last name does Django allow by 
default” on an unrelated technical limit. We’re discussing how long a 
reasonable last name is, not how many bytes MySQL can fit in a varchar without 
incurring an extra byte of overhead for storing the string length.

I have trouble believing that a significant number of people are used to typing 
100+ characters when inputting their name into a website — let alone that a 
significant number of people have a last name that contains more than 100 
characters and that isn’t a joke. How would it fit on a passport?

I know that Brazilian last names are commonly in the 30-50 characters range. 
Going for 60 to have a bit of margin makes sense. If my estimate is too low, we 
could go even further. But 100 and above doesn’t make sense to me.

If you want to allow 255 characters in last names, in my opinion, you’re in the 
territory of custom user models.

> Maybe on Django 3 we can propose a change to "Full name" field ?

There’s a misconception about “Django 3” here. Django will guarantee the same 
compatibility between the last 2.x version and 3.0 than between 2.(x-1) and 2.x.

Apart from that, I think that the most reasonable path to a built-in User model 
not based on first and last name is to ship a new model next to the current one 
and suggest that developers point AUTH_USER_MODEL to that model — or, even 
better, that they inherit the abstract version of the new built-in model in 
their project and point AUTH_USER_MODEL to their copy, so that they can make 
changes later if needed.

Best regards,

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4E860166-BE82-48AF-BF63-4EECC10B03DA%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Extend support for long surnames in Django Auth

[Florian Apolloner]

On Saturday, July 30, 2016 at 3:25:35 PM UTC+2, Raony Guimaraes Corrêa Do 
Carmo Lisboa Cardenas wrote:
>
> So I'm suggesting a change from 30 to 255 characters on last_name field, 
> which is the maximum possible without breaking backwards compatibility. 
> Maybe on Django 3 we can propose a change to "Full name" field ?
>

Technically this is breaking backwards compat, ie there might be other apps 
out there expecting not more than 30 chars as a result of Django's 
limitations. I'd rather see a proposal which does it right before we 
migrate once again. Ie migrate first_name + last_name to full_name and add 
a display_name or similar which saves how a user wants to be addressed. 
This also fixes issues with titles and whatnot.…

Cheers,
Florian 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e8ac1771-8f56-4df1-a621-42effc24c02e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extend support for long surnames in Django Auth

[Raony Guimaraes Corrêa Do Carmo Lisboa Cardenas]

Hello all, here are my thoughts after reading the discussion.

@Erik You won on having the biggest name! Regarding your question about 
"how long is long enough", after checking other web frameworks such as 
rails 
(http://stackoverflow.com/questions/3354330/difference-between-string-and-text-in-rails),
 
I believe the most sensible proposal would be to increase from 30 to 255, 
which is the maximum value permitted for a varchar without changing any 
field in User model.

@Aymeric Agree with you that now with the migrations framework this would 
not be a big issue. Regarding the UI, I argue that this is something we 
already have to deal with, for example, if someone uses all 60 characters 
for first_name and last_name (Ex. "Bommiraju Sitaramanjaneyulu Rajasekhara 
Srinivasulu L S V Sai")  this will probably already break the UI in most 
cases. We can always use {{ last_name|truncatechars:30 }} to fix the UI. I 
mostly believe we should delegate this to the developers of each app and 
not to the users (Ex. that have big surnames).

@Ludovic, is_null and Josh Thank you for the link and suggestions. I agree 
that "Full name" seems to be the most reasonable choice here, but I don't 
want break backwards compatibility, or at least not on this proposal. :)

So I'm suggesting a change from 30 to 255 characters on last_name field, 
which is the maximum possible without breaking backwards compatibility. 
Maybe on Django 3 we can propose a change to "Full name" field ?

Kind Regards.

On Friday, July 29, 2016 at 1:15:43 PM UTC+2, Raony Guimaraes Corrêa Do 
Carmo Lisboa Cardenas wrote:
>
> Hello everyone,
>
> For a long time I was having problems to login to djangopackages.com 
> using my github account (pydanny/djangopackages#338 
> ). After 
> investigating I discovered the problem was because my surname is longer 
> than 30 characters. I don't know why both first_name and last_name fields 
> have the same size limit of 30 characters in Django. That doesn't sound 
> very reasonable.
>
> I'm sure there are other people on the same situation and this already 
> happened with me trying to login in other django websites.
>
>
> [image: selection_086] 
> 
>
>
> Tim Graham suggested I should first ask on this maillist (
> https://github.com/django/django/pull/6988#issuecomment-235945422) to see 
> if there is consensus to make the change.
>
> I would like to ask your opinion about an increase from 30 to 60 
> characters on last_name field so that my login and others won't break again 
> in the future. I can create a Trac ticket if the response is positive.
>
> Kind Regards,
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fe86b3ce-1fcf-4ea5-9082-07a5139ce8d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.