[Django] #29274: Update the password list used by CommonPasswordValidator to a more recent list

[Django]

#29274: Update the password list used by CommonPasswordValidator to a more 
recent
list
-+-
   Reporter:  Brenton|  Owner:  nobody
  Cleeland   |
   Type:  New| Status:  new
  feature|
  Component: |Version:  2.0
  contrib.auth   |   Keywords:
   Severity:  Normal |  CommonPasswordValidator
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 There is a recently released list of common passwords from Troy Hunt /
 Have I Been Pwned that could be used as a basis for the
 CommonPasswordValidator.

 Most of the top 20k have been unhashed and made available here by Royce
 Williams:
 https://gist.github.com/roycewilliams/281ce539915a947a23db17137d91aeb7

 My suggestion would be to use this complete list, but I'd be open to using
 a smaller subset if the community would prefer.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/047.69611ae86b3ae82f1a90b86986399732%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29271: Chaining Filters on a Reverse Foreign Key Produces Multiple Joins

[Django]

#29271: Chaining Filters on a Reverse Foreign Key Produces Multiple Joins
-+-
 Reporter:  Michael MacIntosh|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  filter chain | Triage Stage:  Accepted
  reverse foreign key|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Andrew Standley):

 Thanks for the link Tim, but isn't the scope of #27936 quite a bit
 different? That ticket is regarding possible changes to the
 [https://docs.djangoproject.com/en/dev/topics/db/queries/#spanning-multi-
 valued-relationships spanning multi-value relationships] documentation in
 order to clarify the 'intended' functionality.

 The issue I see is that the
 [https://docs.djangoproject.com/en/2.0/topics/db/queries/#chaining-filters
 chaining-filters] documentation appears to contradict the
 [https://docs.djangoproject.com/en/dev/topics/db/queries/#spanning-multi-
 valued-relationships spanning multi-value relationships] documentation.

 My suggested changes would be more along the lines of
 1) Adding a link to
 [https://docs.djangoproject.com/en/2.0/topics/db/queries/#retrieving-
 specific-objects-with-filters retrieving specific objects with filters] to
 the [https://docs.djangoproject.com/en/2.0/ref/models/querysets/#filter
 filter] docs, so the details of filter are more visible.
 2) Adding a note to
 [https://docs.djangoproject.com/en/2.0/topics/db/queries/#chaining-filters
 chaining-filters] that references the behaviour is handled differently for
 multi-value relationships and links to
 [https://docs.djangoproject.com/en/dev/topics/db/queries/#spanning-multi-
 valued-relationships spanning multi-value relationships] .

 Also a side note for documentation: this ticket appears to be a duplicate
 of #18437 as well.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.b1ec6ce7e8522619472ce5352b68355a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29193: Altering a field with a unique constraint drops and rebuilds FKs to other fields in the table

[Django]

#29193: Altering a field with a unique constraint drops and rebuilds FKs to 
other
fields in the table
-+
 Reporter:  Jeremy Bowman|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.11
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Joshua Massover):

 https://github.com/massover/bug_29193

 The above is a small project to reproduce.

 I could not reproduce it with the built in auth User model. I used a
 custom User model. While using the built in auth User model, it looked
 `_related_non_m2m_objects` did not return my related models because of
 `related_objects`.

 It looks like the code that changed the behavior is this
 
https://github.com/django/django/commit/c3e0adcad8d8ba94b33cabd137056166ed36dae0
 #diff-b69190ab88f6c5737b2562d94d7bf36bR539

 {{{
 # Drop incoming FK constraints if the field is a primary key or
 unique,
 # which might be a to_field target, and things are going to
 change.
 drop_foreign_keys = (
 (
 (old_field.primary_key and new_field.primary_key)
 (old_field.unique and new_field.unique)
 ) and old_type != new_type
 )
 }}}

 Before it would only drop and recreate constraints if the field was a
 foreign key. Now it drops and recreates all constraints if the field is
 unique.

 Naively removing the unique check that was added in
 https://code.djangoproject.com/ticket/28305 will fix this problem. All the
 tests pass. Looking back at the ticket I don't really understand the
 intention, so this seems like an awful idea.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.709b78a3366899aee18d6ec66b72acc5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29251: MySQL backend returns bytes instead of strings in some queries involving database functions

[Django]

#29251: MySQL backend returns bytes instead of strings in some queries involving
database functions
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  mysql bytes  | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felixxm):

 Yes, but I didn't find any specific tickets. I checked that `mysql-
 connector-python` behaves in the same way, then I noticed that MySQL
 returns different data types in both cases, i.e.

  - {{{SELECT LPAD(`test_xyz`.`column1`, CHAR_LENGTH(`test_xyz`.`column2`),
 ' ') AS `filled` FROM `test_xyz`;}}} returns `filled` as a `longtext`,
 probably because it cannot predict a no. of chars,
  - {{{SELECT LPAD(`test_xyz`.`column1`, 2, ' ') AS `filled` FROM
 `test_xyz`;}}} returns `filled` as a `varchar(2)`.


 I also found related discussion
 https://github.com/django/django/pull/3754#discussion_r22146187 and
 following comment "''...Looking briefly at the database driver, it appears
 that longtext/BLOB is defined as returning bytes..."''.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.a861ad8a5cc178f4f9fc27be3f44d636%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29273: MultipleChoiceField incorrectly selects the empty value for an empty form (was: MultipleChoiceField auto selects on initial load the empty value)

[Django]

#29273: MultipleChoiceField incorrectly selects the empty value for an empty 
form
--+
 Reporter:  Tim Kleinschmidt  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Forms |  Version:  1.11
 Severity:  Release blocker   |   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham):

 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


Comment:

 The difference can be seen here:
 {{{
 from django import forms
 choices = [('', '(no extra)'), ('cheese', 'Cheese'), ('Pepper', 'Pepper')]
 class Form(forms.Form):
 extra_topics = forms.MultipleChoiceField(required=False,
 choices=choices)

 form = Form()
 print(form)
 }}}
 The first option renders as `(no
 extra)` in Django 1.11+ but without `selected` in older versions.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.4fdc5f8d693bd446790ff003033e3f69%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #470: Add Field.db_default for defining database defaults

[Django]

#470: Add Field.db_default for defining database defaults
-+-
 Reporter:  jws  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  normal   |   Resolution:
 Keywords:  sql schema   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ryan Hiebert):

 * cc: Ryan Hiebert (added)


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.58f0711c8c70bb4a78aaf155bb370254%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29270: KeyError if using 'password' as readonly_fields in UserAdmin

[Django]

#29270: KeyError if using 'password' as readonly_fields in UserAdmin
--+---
 Reporter:  Malte Gerth   |Owner:  Malte Gerth
 Type:  Bug   |   Status:  closed
Component:  contrib.auth  |  Version:  2.0
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+---
Changes (by Tim Graham ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"874977d388decdd59022bf6b7f4d50caf2052155" 874977d3]:
 {{{
 #!CommitTicketReference repository=""
 revision="874977d388decdd59022bf6b7f4d50caf2052155"
 Fixed #29270 -- Fixed UserChangeForm crash if password field is excluded.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.662d64324551d3552e699391913249e2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29272: Queryset using order_by(F()) fails to compile with values_list

[Django]

#29272: Queryset using order_by(F()) fails to compile with values_list
-+-
 Reporter:  bszfw|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 Could you possibly provide the exact traceback you encounter?

 Also you should be able to pass your expression directly to `order_by`


 {{{#!python
 Question.objects.order_by(
 Value(1, output_field=IntegerField()).asc(nulls_last=True),
 ).values_list('question_text')
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.558ff936ba6bca44d5ea19f37d03a404%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29271: Chaining Filters on a Reverse Foreign Key Produces Multiple Joins

[Django]

#29271: Chaining Filters on a Reverse Foreign Key Produces Multiple Joins
-+-
 Reporter:  Michael MacIntosh|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  filter chain | Triage Stage:  Accepted
  reverse foreign key|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 #27936 requests documentation improvements.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.0f423bba1361da8c22d03fa1cadbf5ee%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29251: MySQL backend returns bytes instead of strings in some queries involving database functions

[Django]

#29251: MySQL backend returns bytes instead of strings in some queries involving
database functions
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  mysql bytes  | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Did you search for a MySQL ticket about this so we know if the behavior
 might change in future versions?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.4c7e2baeac2a0b0053841eff5e3f8a26%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29271: Chaining Filters on a Reverse Foreign Key Produces Multiple Joins

[Django]

#29271: Chaining Filters on a Reverse Foreign Key Produces Multiple Joins
-+-
 Reporter:  Michael MacIntosh|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  filter chain | Triage Stage:  Accepted
  reverse foreign key|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Andrew Standley):

 I'm pretty sure it's a good rule of thumb that when the behaviour of a
 feature is highly unintuitive, one should question whether it was a good
 design choice. I'll take this to the mailing list in the hope someone can
 explain the justification for this intended behaviour because ,to my naive
 self, it seems that `Q` objects would be a cleaner way to allow the type
 of multi-valued queries referenced in
 [https://docs.djangoproject.com/en/dev/topics/db/queries/#spanning-multi-
 valued-relationships spanning multi-valued relationships].

 I would argue that regardless, this is an issue with the documentation as
 Simon suggests.

 The [https://docs.djangoproject.com/en/2.0/ref/models/querysets/#filter
 filter] documentation simply states that filters are joined via AND.
 Meanwhile the [https://docs.djangoproject.com/en/2.0/topics/db/queries
 /#chaining-filters chaining filters] documentation explicitly states that
 successive filters act on the result of the last filter. Neither have any
 link or reference to the contradictory behaviour documented in
 [https://docs.djangoproject.com/en/dev/topics/db/queries/#spanning-multi-
 valued-relationships spanning multi-valued relationships]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.f7bd2839714310ec8cc6556385b0095b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29273: MultipleChoiceField auto selects on initial load the empty value

[Django]

#29273: MultipleChoiceField auto selects on initial load the empty value
--+--
 Reporter:  Tim Kleinschmidt  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Forms |  Version:  1.11
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by Tim Graham):

 Can you please be more explicit about the steps to reproduce the issue?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.6bd5d7cde927b964b4e8379407e89219%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #470: Add Field.db_default for defining database defaults

[Django]

#470: Add Field.db_default for defining database defaults
-+-
 Reporter:  jws  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  normal   |   Resolution:
 Keywords:  sql schema   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Paul Tiplady):

 Further justification for this feature -- it makes zero-downtime DB
 migrations easier: https://code.djangoproject.com/ticket/29266

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.17bf7784afe2324604ea3dfd00874691%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29193: Altering a field with a unique constraint drops and rebuilds FKs to other fields in the table

[Django]

#29193: Altering a field with a unique constraint drops and rebuilds FKs to 
other
fields in the table
-+
 Reporter:  Jeremy Bowman|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.11
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Jeremy Bowman):

 Sure, I'll go ahead and attempt a patch sometime in the next few days.
 I'm helping deploy the upgrade to Django 1.11 on our main service today,
 so my availability will partially depend on how smoothly that goes.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.27e4e50ff366e97c8c8606b713a83d14%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29273: MultipleChoiceField auto selects on initial load the empty value

[Django]

#29273: MultipleChoiceField auto selects on initial load the empty value
--+--
 Reporter:  Tim Kleinschmidt  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Forms |  Version:  1.11
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by Tim Kleinschmidt):

 * type:  Uncategorized => Bug


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.36f60e84d088f3c25f27a34a5288c1b1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29273: MultipleChoiceField auto selects on initial load the empty value

[Django]

#29273: MultipleChoiceField auto selects on initial load the empty value
+
   Reporter:  Tim Kleinschmidt  |  Owner:  nobody
   Type:  Uncategorized | Status:  new
  Component:  Forms |Version:  1.11
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 hi,

 I upgraded Django from 1.8 to 1.11, in the last month and we have now a
 bug that the empty choice is always selected on initial page load and
 leads to confusion. If I deselect and select the value it work like
 intended.

 It seems for me that there is no
 [https://github.com/django/django/blob/1.11.11/django/forms/widgets.py#L591
 check] if something was already selected or if it be a fresh form. Like it
 was in
 [https://github.com/django/django/blob/1.8.19/django/forms/widgets.py#L523
 1.8] in `selected_choices`

 I think this report also apply to the `ModelMultipleChoiceField`



 e.g.
 {{{
 #!div style="font-size: 80%"
 Code highlighting:
   {{{#!python
   choices = [(u'', '(no extra)'), (u'cheese', u'Cheese'), (u'Pepper',
 u'Pepper')]
   extra_topics = forms.MultipleChoiceField(required=False,
 choices=choices)
   }}}
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/049.15b356c8a65681f474b2433439e3a31d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29268: Support passing None to test Client and RequestFactory request methods for default content_type

[Django]

#29268: Support passing None to test Client and RequestFactory request methods 
for
default content_type
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Chris Jerdonek):

 I started working on this here:
 https://github.com/cjerdonek/django/tree/ticket_29268

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.1637cd3f070c9493a988ee7284acc24b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29270: KeyError if using 'password' as readonly_fields in UserAdmin

[Django]

#29270: KeyError if using 'password' as readonly_fields in UserAdmin
--+---
 Reporter:  Malte Gerth   |Owner:  Malte Gerth
 Type:  Bug   |   Status:  assigned
Component:  contrib.auth  |  Version:  2.0
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+---

Comment (by Malte Gerth):

 Ok, I tried to make a pull request
 https://github.com/django/django/pull/9833

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.572ad1c1fd893fc9a7d359d10792154e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29272: Queryset using order_by(F()) fails to compile with values_list

[Django]

#29272: Queryset using order_by(F()) fails to compile with values_list
-+-
   Reporter:  bszfw  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  2.0
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Here is a simplified version of what I am trying to do:

 {{{
 from django.db import models
 from django.db.models import IntegerField, F, Value

 class Question(models.Model):
 question_text = models.CharField(max_length=200)
 pub_date = models.DateTimeField('date published')

 def __str__(self):
 return self.question_text

 Question.objects.annotate(test=Value(1,
 output_field=IntegerField())).order_by(F('test')).values_list('question_text')
 }}}

 It works without using {{{F}}}, or by adding the annotated value to
 {{{values_list}}}.
 But I need {{{F}}} to be able to write
 {{{F('test').asc(nulls_last=True)}}}, and I cannot modify
 {{{values_list}}} as it is added to the Queryset later in code which does
 not know anything about the annotation.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/048.49ef73b6f66a09c352ee716b56877513%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29268: Support passing None to test Client and RequestFactory request methods for default content_type (was: Support passing content_type=None to test.Client.post() to get the default va

[Django]

#29268: Support passing None to test Client and RequestFactory request methods 
for
default content_type
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Chris Jerdonek):

 * owner:  nobody => Chris Jerdonek
 * status:  new => assigned


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.046e5cd6f385b61b4aefb4b0380e6802%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.