Re: [Django] #27002: Redundant database query rendering a ModelChoiceField with RadioSelect or CheckboxSelectMultiple

[Django]

#27002: Redundant database query rendering a ModelChoiceField with RadioSelect 
or
CheckboxSelectMultiple
--+--
 Reporter:  AlexHill  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Forms |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by AlexHill):

 * has_patch:  0 => 1


Comment:

 Implementation of (2) at
 https://github.com/django/django/compare/master...AlexHill:ticket_27002

 That patch builds in #27001, so I haven't opened a PR for it yet.

--
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.1d8bcabbcfe56c714d8a586471a09dfa%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27003: ArrayField and JSONField form fields fail on already converted values

[Django]

#27003: ArrayField and JSONField form fields fail on already converted values
-+-
 Reporter:  brandonchinn178  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  postgres,| Triage Stage:
  arrayfield |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by brandonchinn178):

 Fixed in pull request: https://github.com/django/django/pull/7012

--
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/073.12b3ab4845dc02d2a0c39e746420964d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27003: ArrayField and JSONField form fields fail on already converted values

[Django]

#27003: ArrayField and JSONField form fields fail on already converted values
-+-
 Reporter:  brandonchinn178  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  postgres,| Triage Stage:
  arrayfield |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by brandonchinn178):

 * needs_better_patch:   => 0
 * has_patch:  0 => 1
 * needs_tests:   => 0
 * needs_docs:   => 0


--
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/073.6b653aef34d659c4932bf7582b225a2e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27003: ArrayField and JSONField form fields fail on already converted values

[Django]

#27003: ArrayField and JSONField form fields fail on already converted values
-+--
 Reporter:  brandonchinn178  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Forms|Version:  1.10
 Severity:  Normal   |   Keywords:  postgres, arrayfield
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  1|  UI/UX:  0
-+--
 If I make a model `Foo` with the PostgreSQL `ArrayField`,

 {{{
 class Foo(models.Model):
 bar = ArrayField(models.CharField(...))
 }}}

 And create a `ModelForm`:

 {{{
 FooForm = modelform_factory(Foo, excludes=[])
 }}}

 The field will fail with already-converted values, like

 {{{
 foo = Foo.objects.create(bar=['a', 'b'])
 data = model_to_dict(foo) # {'bar': ['a', 'b']}
 form = FooForm(instance=foo, data=data)
 form.full_clean() # errors at django/contrib/postgres/forms/array.py:39
 }}}

 Shouldn't already converted values be checked in the `to_python` method of
 `ArrayField`? (Same with `JSONField`)

--
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/058.6db984bf256fe6cd30288360917625fe%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27002: Redundant database query rendering a ModelChoiceField with RadioSelect or CheckboxSelectMultiple

[Django]

#27002: Redundant database query rendering a ModelChoiceField with RadioSelect 
or
CheckboxSelectMultiple
--+--
 Reporter:  AlexHill  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Forms |  Version:  1.10
 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 AlexHill):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Old description:

> Followup to #27001:
>
> Rendering a ModelChoiceField with RadioSelect and CheckboxSelectMultiple,
> there's a redundant iteration that triggers an unnecessary database call.
>
> Here's the relevant code from ForNode.render
> ([https://github.com/django/django/blob/ccd5a23fba91e66656bb19b60bb6d737cab728f5/django/template/defaulttags.py#L164
> GitHub link]):
>
> {{{#!python
> if not hasattr(values, '__len__'):  # line 164
> values = list(values)
> len_values = len(values)
> ...
> for i, item in enumerate(values):  # line 177
> ...
> }}}
>
> In this code, `values` is a BoundField. BoundField defines \__len__ like
> this:
>
> {{{#!python
> def __len__(self):
> return len(list(self.__iter__()))
> }}}
>
> So `len(values)` on line 164 triggers an iteration over `values` (and
> thus a database query), then the for loop at line 177 triggers another.
>
> The options as I see them are
> 1. Remove `BoundField.__len__` so that `list(values)` is called in
> `ForNode.render`. This fixes the problem without breaking any tests. It
> is backwards-incompatible (e.g. with an existing template passing a
> boundfield to the `length` template filter), but not with anything
> documented.
> 2. Cache iterator results somewhere internally so that the actual query
> is only executed once. This is easy to do on BoundField with a cached
> property. No backward compatibility concerns here.
> 3. Unconditionally call `list(values)` in ForNode. Also works, but a bit
> heavy-handed and not necessary if one of the first two options are
> acceptable.
>
> I think (2) is the best choice. It's pretty clean, and it means the fix
> can be implemented in 1.10 (and 1.8 LTS?) as a bug fix without backward
> compatibility concerns.

New description:

 Followup to #27001:

 Rendering a ModelChoiceField with RadioSelect and CheckboxSelectMultiple,
 there's a redundant iteration that triggers an unnecessary database call.

 Here's the relevant code from ForNode.render
 
([https://github.com/django/django/blob/ccd5a23fba91e66656bb19b60bb6d737cab728f5/django/template/defaulttags.py#L164
 GitHub link]):

 {{{#!python
 if not hasattr(values, '__len__'):  # line 164
 values = list(values)
 len_values = len(values)
 ...
 for i, item in enumerate(values):  # line 177
 ...
 }}}

 In this code, `values` is a BoundField. BoundField defines `__len__` like
 this:

 {{{#!python
 def __len__(self):
 return len(list(self.__iter__()))
 }}}

 So `len(values)` on line 164 triggers an iteration over `values` (and thus
 a database query), then the for loop at line 177 triggers another.

 The options as I see them are
 1. Remove `BoundField.__len__` so that `list(values)` is called in
 `ForNode.render`. This fixes the problem without breaking any tests. It is
 backwards-incompatible (e.g. with an existing template passing a
 boundfield to the `length` template filter), but not with anything
 documented.
 2. Cache iterator results somewhere internally so that the actual query is
 only executed once. This is easy to do on BoundField with a cached
 property. No backward compatibility concerns here.
 3. Unconditionally call `list(values)` in ForNode. Also works, but a bit
 heavy-handed and not necessary if one of the first two options are
 acceptable.

 I think (2) is the best choice. It's pretty clean, and it means the fix
 can be implemented in 1.10 (and 1.8 LTS?) as a bug fix without backward
 compatibility concerns.

--

--
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.541c9f

[Django] #27002: Redundant database query rendering a ModelChoiceField with RadioSelect or CheckboxSelectMultiple

[Django]

#27002: Redundant database query rendering a ModelChoiceField with RadioSelect 
or
CheckboxSelectMultiple
+
 Reporter:  AlexHill|  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Forms   |Version:  1.10
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 Followup to #27001:

 Rendering a ModelChoiceField with RadioSelect and CheckboxSelectMultiple,
 there's a redundant iteration that triggers an unnecessary database call.

 Here's the relevant code from ForNode.render
 
([https://github.com/django/django/blob/ccd5a23fba91e66656bb19b60bb6d737cab728f5/django/template/defaulttags.py#L164
 GitHub link]):

 {{{#!python
 if not hasattr(values, '__len__'):  # line 164
 values = list(values)
 len_values = len(values)
 ...
 for i, item in enumerate(values):  # line 177
 ...
 }}}

 In this code, `values` is a BoundField. BoundField defines \__len__ like
 this:

 {{{#!python
 def __len__(self):
 return len(list(self.__iter__()))
 }}}

 So `len(values)` on line 164 triggers an iteration over `values` (and thus
 a database query), then the for loop at line 177 triggers another.

 The options as I see them are
 1. Remove `BoundField.__len__` so that `list(values)` is called in
 `ForNode.render`. This fixes the problem without breaking any tests. It is
 backwards-incompatible (e.g. with an existing template passing a
 boundfield to the `length` template filter), but not with anything
 documented.
 2. Cache iterator results somewhere internally so that the actual query is
 only executed once. This is easy to do on BoundField with a cached
 property. No backward compatibility concerns here.
 3. Unconditionally call `list(values)` in ForNode. Also works, but a bit
 heavy-handed and not necessary if one of the first two options are
 acceptable.

 I think (2) is the best choice. It's pretty clean, and it means the fix
 can be implemented in 1.10 (and 1.8 LTS?) as a bug fix without backward
 compatibility concerns.

--
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/051.e33d244f20020c2d5fee6df85ec740f5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27001: Regression in query counts using RadioSelect with ModelChoiceField

[Django]

#27001: Regression in query counts using RadioSelect with ModelChoiceField
-+
 Reporter:  AlexHill |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.10
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by charettes):

 * severity:  Normal => Release blocker
 * needs_tests:  1 => 0


Comment:

 As this is a regression in 1.10 I suppose this should be backported.

--
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.ec2916b15429e67272a42ba30030b881%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27001: Regression in query counts using RadioSelect with ModelChoiceField

[Django]

#27001: Regression in query counts using RadioSelect with ModelChoiceField
--+
 Reporter:  AlexHill  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Forms |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by charettes):

 * stage:  Unreviewed => Accepted


Comment:

 [https://github.com/django/django/pull/7011 PR]

--
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.2c10f58a3c621168b8220408ec127e24%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27001: Regression in query counts using RadioSelect with ModelChoiceField

[Django]

#27001: Regression in query counts using RadioSelect with ModelChoiceField
--+--
 Reporter:  AlexHill  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Forms |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by AlexHill):

 * has_patch:  0 => 1
 * type:  Uncategorized => Bug
 * needs_tests:  0 => 1


--
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.a69de6da39d31303c4bf539c6d54471e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27001: Regression in query counts using RadioSelect with ModelChoiceField

[Django]

#27001: Regression in query counts using RadioSelect with ModelChoiceField
---+--
 Reporter:  AlexHill   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Forms  |  Version:  1.10
 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 AlexHill):

 Created a pull request with a fix.

 `ChoiceFieldRenderer` doesn't have `__iter__` defined, so Python iterates
 over it by calling `__getitem__` with an increasing index until an
 exception is raised. `ChoiceFieldRenderer.__getitem__` calls `list` on
 itself, which turns iteration into an n^2 operation. When the choices are
 backed by a queryset as in ModelChoiceField, that means lots of redundant
 database queries.

 Fixed by adding an `__iter__` method to `ChoiceFieldRenderer` and changing
 `__getitem__` to use it, so that indexing still works.

--
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.649c881843ddf8ad39feb0dd03fd1361%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27001: Regression in query counts using RadioSelect with ModelChoiceField

[Django]

#27001: Regression in query counts using RadioSelect with ModelChoiceField
---+--
 Reporter:  AlexHill   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Forms  |  Version:  1.10
 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 AlexHill):

 Branch with failing test here:
 https://github.com/django/django/compare/master...AlexHill:ticket_27001

--
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.dcfa2cbd6498885643227220801a4255%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27001: Regression in query counts using RadioSelect with ModelChoiceField

[Django]

#27001: Regression in query counts using RadioSelect with ModelChoiceField
---+--
 Reporter:  AlexHill   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Forms  |  Version:  1.10
 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 AlexHill):

 * needs_better_patch:   => 0
 * component:  Uncategorized => Forms
 * needs_tests:   => 0
 * needs_docs:   => 0


--
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.dea4efe44d7337fc1102d42ae5a22f56%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27001: Regression in query counts using RadioSelect with ModelChoiceField

[Django]

#27001: Regression in query counts using RadioSelect with ModelChoiceField
---+
 Reporter:  AlexHill   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.10
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Before 1.9, I had on my list of things to look at the fact that a standard
 ModelChoiceField with a RadioSelect takes two queries. Now looking at this
 in 1.10, the number of queries has ballooned (to 11 queries in my simple
 test case).

 I've not got far in looking for a solution, but this test passes in 1.9
 and fails in 1.10 and master with `AssertionError: 11 != 2 : 11 queries
 executed, 2 expected`:

 {{{#!python
 def test_radioselect_num_queries(self):
 class CategoriesForm(forms.Form):
 categories = forms.ModelChoiceField(
 queryset=Category.objects.all(),
 widget=forms.RadioSelect
 )

 template = Template('{% for w in form.categories %}{{ w }}{%
 endfor %}')

 with self.assertNumQueries(2):
 template.render(Context({'form': CategoriesForm()}))
 }}}

--
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/051.bdea3a7a0bad5da4d1b951be5008aabb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26999: Request to add changes to ``model_to_dict`` in Django 1.10 to the release notes

[Django]

#26999: Request to add changes to ``model_to_dict`` in Django 1.10 to the 
release
notes
--+
 Reporter:  aronysidoro   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0
 * has_patch:  0 => 1
 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 We don't normally document private API changes, however, my sense is that
 `model_to_dict()` is widely used even though it's not documented. How
 about:
 {{{
 * Private API ``django.forms.models.model_to_dict()`` returns a queryset
 for
   ``ManyToManyField``\s rather than a list of IDs.
 }}}

--
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/069.44e25892d2bd6e3075527671fa0bae5e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27000: Django manage Command.usage() is broken

[Django]

#27000: Django manage Command.usage() is broken
-+-
 Reporter:  throwable-one|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Management |  Version:  1.10
  commands)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"7dd8e53cc834b65a2665d0bb63662db4051469b4" 7dd8e53c]:
 {{{
 #!CommitTicketReference repository=""
 revision="7dd8e53cc834b65a2665d0bb63662db4051469b4"
 [1.10.x] Fixed #27000 -- Removed BaseCommand.usage() per deprecation
 timeline (refs #19973).

 Backport of ccd5a23fba91e66656bb19b60bb6d737cab728f5 from master
 }}}

--
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.254f38440c909c21f1052f487a261c08%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #19973: Management commands migration to argparse

[Django]

#19973: Management commands migration to argparse
-+-
 Reporter:  jose |Owner:  jose
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  optparse, argparse,  | Triage Stage:  Ready for
  basecommand|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"7dd8e53cc834b65a2665d0bb63662db4051469b4" 7dd8e53c]:
 {{{
 #!CommitTicketReference repository=""
 revision="7dd8e53cc834b65a2665d0bb63662db4051469b4"
 [1.10.x] Fixed #27000 -- Removed BaseCommand.usage() per deprecation
 timeline (refs #19973).

 Backport of ccd5a23fba91e66656bb19b60bb6d737cab728f5 from master
 }}}

--
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/062.68f62b73e1ba0e6aa2cee799ed7aed70%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #19973: Management commands migration to argparse

[Django]

#19973: Management commands migration to argparse
-+-
 Reporter:  jose |Owner:  jose
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  optparse, argparse,  | Triage Stage:  Ready for
  basecommand|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"ccd5a23fba91e66656bb19b60bb6d737cab728f5" ccd5a23f]:
 {{{
 #!CommitTicketReference repository=""
 revision="ccd5a23fba91e66656bb19b60bb6d737cab728f5"
 Fixed #27000 -- Removed BaseCommand.usage() per deprecation timeline (refs
 #19973).
 }}}

--
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/062.811d74abd16240b019aaadb3a227d74f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27000: Django manage Command.usage() is broken

[Django]

#27000: Django manage Command.usage() is broken
-+-
 Reporter:  throwable-one|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Management |  Version:  1.10
  commands)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"ccd5a23fba91e66656bb19b60bb6d737cab728f5" ccd5a23f]:
 {{{
 #!CommitTicketReference repository=""
 revision="ccd5a23fba91e66656bb19b60bb6d737cab728f5"
 Fixed #27000 -- Removed BaseCommand.usage() per deprecation timeline (refs
 #19973).
 }}}

--
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.063b166a49caaf01d58cb21b8594590e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27000: Django manage Command.usage() is broken

[Django]

#27000: Django manage Command.usage() is broken
-+-
 Reporter:  throwable-one|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Management |  Version:  1.10
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by charettes):

 @throwable-one, you can probably achieve similar result by using
 `Command().create_parser`.

--
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.2f78d62e33ba45bd8b41287c13a7099f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26445: Can't set password on User during migration that depends on contrib.auth

[Django]

#26445: Can't set password on User during migration that depends on contrib.auth
-+-
 Reporter:  giuliettamasina  |Owner:
 |  giuliettamasina
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by orzel):

 * cc: django2.20.orzelf@… (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/073.7e8316763223a59cff1459e2b8c7e895%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26981: Support passing custom kwargs to DiscoverRunner's test runner

[Django]

#26981: Support passing custom kwargs to DiscoverRunner's test runner
---+-
 Reporter:  cjerdonek  |Owner:  cjerdonek
 Type:  New feature|   Status:  assigned
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-
Changes (by cjerdonek):

 * has_patch:  0 => 1


Comment:

 I posted a pull request for this in my GitHub repo
 [https://github.com/django/django/pull/7009 here].

--
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.2b19052ef9f782d9305f3eb393269ad5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26998: E013 check is over-zealous

[Django]

#26998: E013 check is over-zealous
---+--
 Reporter:  aaugustin  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.10
 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 timgraham):

 I'd guess 983c158da7723eb00a376bd31db76709da4d0260 is at fault. I was
 skeptical of the usefulness of that change and don't mind reverting parts
 of it as needed if an alternative isn't proposed.

--
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.6dd198d18cec5eef5a8c516a56a3bb76%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27000: Django manage Command.usage() is broken

[Django]

#27000: Django manage Command.usage() is broken
-+-
 Reporter:  throwable-one|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Management |  Version:  1.10
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0
 * has_patch:  0 => 1
 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 It looks like that method should have been removed along with `optparse`
 support in 6a70cb53971a19f2d9e71d5ee24bfb0e844b4d9d.

 [https://github.com/django/django/pull/7008 PR]

--
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.ba5daa3e6d04ff9affefabcd6c5ec3c6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27000: Django manage Command.usage() is broken

[Django]

#27000: Django manage Command.usage() is broken
+
 Reporter:  throwable-one   |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Core (Management commands)  |Version:  1.10
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 This method access self.args which is not set.

 How to reproduce:
 {{{

 import os

 import django

 os.environ.setdefault("DJANGO_SETTINGS_MODULE", "untitled8.settings")


 django.setup()

 from django.core.management.commands import createcachetable

 createcachetable.Command().usage("")
 }}}

 Result:
 {{{
 usage = '%%prog %s [options] %s' % (subcommand, self.args)
 AttributeError: 'Command' object has no attribute 'args'
 }}}

--
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/056.d702d139be98ff1a2cc6a2fe93b498ff%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26999: Request to add changes to ``model_to_dict`` in Django 1.10 to the release notes

[Django]

#26999: Request to add changes to ``model_to_dict`` in Django 1.10 to the 
release
notes
---+
 Reporter:  aronysidoro|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.10
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 It seems that the `django.forms.models.model_to_dict` function changed
 with the way that it treats many-to-many related objects. Before, it was
 returning them in a list if ID's. Not it's returning them as a queryset.

 Commit that caused the change:

 
https://github.com/django/django/commit/ded502024191053475bac811d365ac29dca1db61

 The logic is here in the `model_to_dict` method:

 https://github.com/django/django/blob/1.10/django/forms/models.py#L91

 And here in the field method:

 
https://github.com/django/django/blob/1.10/django/db/models/fields/related.py#L1564-L1570

 I'd like to request to add this to the release notes for Django 1.10.  I
 couldn't find any note of it in there.  I didn't know about the change,
 and it caused some code to break. No big deal, was able to locate the
 issue. Just want to point it out in case others may experience it.

 Thank you

--
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/054.fa403957437914ac8bf4590d6a320196%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26984: Data Migrations and auto_now

[Django]

#26984: Data Migrations and auto_now
-+--
 Reporter:  fizista  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 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 charettes):

 * status:  new => closed
 * resolution:   => wontfix


Comment:

 I'll resolve as ''wontfix'' in this case as migrations were designed to
 carry model state around in order to make models available through
 `RunPython` operations behave just like normal models would at certain
 point in a project.

 I see no compelling reason to make `auto_now` or `auto_now_add` behave
 differently when used in data migrations.

--
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.80aba28aadda7fe04357710f31cfed65%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26984: Data Migrations and auto_now

[Django]

#26984: Data Migrations and auto_now
-+--
 Reporter:  fizista  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Migrations   |  Version:  master
 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 fizista):

 Yes, I mean operations run in the "RunPython".
 We can always use the "update_fields" in the method save.

--
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.4fda69b3713cddd7f0b8853a0bcbf7fd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26986: `force_login` requires `user.is_active` in 1.10

[Django]

#26986: `force_login` requires `user.is_active` in 1.10
--+
 Reporter:  Tordek|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Tordek):

 I have a custom user model that is valid when its `validation_date` is
 set.

 Simplified:
 {{{
 class MyUser(AbstractBaseUser, PermissionsMixin):
 email = models.CharField(max_length=255, unique=True)
 validation_date = models.DateTimeField(null=True)

 USERNAME_FIELD = 'email'

 @property
 def is_active(self):
 return self.validation_date is not None
 }}}

 I have a test on a view that requires login, like

 {{{
 def test_user_must_be_logged_in(self):
 response = self.client.get("some.url")
 self.assertRedirects(response, "/login/?next=some.url")

 self.client.force_login(self.user)
 response = self.client.get("some.url")
 self.assertEqual(200, response.status_code)
 }}}

 This test worked in 1.9 but is broken in 1.10; the user is not logged in
 unless I assign a value to `validation_date` and save (i.e., unless the
 user's `is_active` returns `True`).

 If you require a complete example, just ask :)

--
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.8d15de0da0b7ce6dd211cfd0eca3c0bf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26996: Upgrade path for custom Context subclasses isn't documented

[Django]

#26996: Upgrade path for custom Context subclasses isn't documented
---+--
 Reporter:  pembo13|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.10
 Severity:  Normal |   Resolution:  wontfix
 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 pembo13):

 Sorry for being unclear. I wasn't filing this ticket to try to solve my
 problem, I handled that separately, just pointing out the lack of
 forewarning in the reference material and release notes.

--
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.f730f64341389dd340ef6306146f3c40%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26996: Upgrade path for custom Context subclasses isn't documented

[Django]

#26996: Upgrade path for custom Context subclasses isn't documented
---+--
 Reporter:  pembo13|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.10
 Severity:  Normal |   Resolution:  wontfix
 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 aaugustin):

 Well, technically, you could try passing a subclass of `dict` as the
 `context` argument of `render_to_response`.

 I have no idea whether this is a reasonable way to achieve your goals,
 since I don't know what you're trying to do, and this is likely not the
 first thing I would attempt. I'd probably go for a custom template backend
 if I needed this level of customization. Look at
 `django.template.backends.django`, there isn't a lot of code in there.

--
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.545daf04fd9866d32813ffa5227a6481%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26998: E013 check is over-zealous

[Django]

#26998: E013 check is over-zealous
---+--
 Reporter:  aaugustin  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.10
 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 aaugustin):

 This is all the more frustrating since `TaggableManager` — a `Field` class
 — implements a custom `formfield` method to build its admin widget (that's
 a public API) so a check justified by the admin M2M widget doesn't make
 sense in any case.

--
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.35aec44039e2adddc5a1f00ec5bebcb8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26998: E013 check is over-zealous

[Django]

#26998: E013 check is over-zealous
---+--
 Reporter:  aaugustin  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.10
 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
---+--
Description changed by aaugustin:

Old description:

> After upgrading a project to Django 1.10, it failed to start because of a
> system check:
>
> {{{
> : (admin.E013) The value of
> 'fieldsets[2][1]["fields"]' cannot include the many-to-many field 'tags'
> because that field manually specifies a relationship model.
> }}}
>
> The corresponding M2M field is managed by django-taggit.
>
> It's declared as follows:
>
> {{{
> tags = TaggableManager(
> verbose_name="libellés", blank=True,
> through=TaggedPost, related_name='tag+')
> }}}
>
> and the manager is just:
>
> {{{
> class TaggedPost(TaggedItemBase):
> content_object = models.ForeignKey("blog.Post")
> }}}
>
> I suppose the intent of this check is to prevent developers from using
> the admin's M2M widget when the through model has extra fields.
>
> However, in my case, the through model doesn't have extra fields, so the
> check isn't testing the right thing.
>
> This issue didn't happen with Django 1.9 because the test for this check
> was written slightly differently and django-taggit slipped through the
> cracks.
>
> It's likely possible to work around this issue with a hack in django-
> taggit, but it seems to me that this check doesn't use the right logic
> and could be improved, so I'm filing this ticket.

New description:

 After upgrading a project to Django 1.10, it failed to start because of a
 system check:

 {{{
 : (admin.E013) The value of
 'fieldsets[2][1]["fields"]' cannot include the many-to-many field 'tags'
 because that field manually specifies a relationship model.
 }}}

 The corresponding M2M field is managed by django-taggit.

 It's declared as follows:

 {{{
 tags = TaggableManager(
 verbose_name="libellés", blank=True,
 through=TaggedPost, related_name='tag+')
 }}}

 and the manager is just:

 {{{
 class TaggedPost(TaggedItemBase):
 content_object = models.ForeignKey("blog.Post")
 }}}

 I suppose the intent of this check is to prevent developers from using the
 admin's M2M widget when the through model has extra fields.

 However, in my case, the through model doesn't have extra fields, so the
 check isn't testing the right thing.

 This issue didn't happen with Django 1.9 because the test for this check
 was written slightly differently and django-taggit slipped through the
 cracks.

 It's likely possible to work around this issue with a hack in django-
 taggit, but it seems to me that this check doesn't use the right logic and
 could be improved, so I'm filing this ticket.

 The corresponding issue django-taggit is https://github.com/alex/django-
 taggit/issues/430.

--

--
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.b3649a7f41793119e00c2d4898f11193%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26998: E013 check is over-zealous

[Django]

#26998: E013 check is over-zealous
-+
   Reporter:  aaugustin  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  contrib.admin  |Version:  1.10
   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  |
-+
 After upgrading a project to Django 1.10, it failed to start because of a
 system check:

 {{{
 : (admin.E013) The value of
 'fieldsets[2][1]["fields"]' cannot include the many-to-many field 'tags'
 because that field manually specifies a relationship model.
 }}}

 The corresponding M2M field is managed by django-taggit.

 It's declared as follows:

 {{{
 tags = TaggableManager(
 verbose_name="libellés", blank=True,
 through=TaggedPost, related_name='tag+')
 }}}

 and the manager is just:

 {{{
 class TaggedPost(TaggedItemBase):
 content_object = models.ForeignKey("blog.Post")
 }}}

 I suppose the intent of this check is to prevent developers from using the
 admin's M2M widget when the through model has extra fields.

 However, in my case, the through model doesn't have extra fields, so the
 check isn't testing the right thing.

 This issue didn't happen with Django 1.9 because the test for this check
 was written slightly differently and django-taggit slipped through the
 cracks.

 It's likely possible to work around this issue with a hack in django-
 taggit, but it seems to me that this check doesn't use the right logic and
 could be improved, so I'm filing this ticket.

--
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/052.9ef235aae1fcf16a4794b942846fb801%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26992: On admin change view, exception raised from __unicode__ method of model related by fk is "hidden" and instead view without form shown

[Django]

#26992: On admin change view, exception raised from __unicode__ method of model
related by fk is "hidden" and instead view without form shown
-+-
 Reporter:  okrutny  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.9
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  change empty | Triage Stage:
  exception  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * status:  new => closed
 * resolution:   => needsinfo


Comment:

 If that's not the issue, then please provide a more complete sample
 project that reproduces the issue and reopen the ticket. Thanks.

--
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.b2ab650711f931474724eea598d942c2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26997: crash on empty model permissions

[Django]

#26997: crash on empty model permissions
-+
 Reporter:  hellpain |Owner:  hellpain
 Type:  Bug  |   Status:  assigned
Component:  contrib.auth |  Version:  1.10
 Severity:  Release blocker  |   Resolution:
 Keywords:  permissions  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+
Changes (by hellpain):

 * status:  new => assigned
 * owner:  nobody => hellpain


--
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.e426d70db4470774a2aa19f3f23041f7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26997: crash on empty model permissions

[Django]

#26997: crash on empty model permissions
-+
 Reporter:  hellpain |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  1.10
 Severity:  Release blocker  |   Resolution:
 Keywords:  permissions  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+

Comment (by hellpain):

 Added PR and release notes

--
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.a21d13f40f78764663835ccedc91eed4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26981: Support passing custom kwargs to DiscoverRunner's test runner

[Django]

#26981: Support passing custom kwargs to DiscoverRunner's test runner
---+-
 Reporter:  cjerdonek  |Owner:  cjerdonek
 Type:  New feature|   Status:  assigned
Component:  Testing framework  |  Version:  master
 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 timgraham):

 * type:  Uncategorized => New feature
 * stage:  Unreviewed => Accepted


--
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.5921d9c1ad3c64639c50e81d75e77be5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26997: crash on empty model permissions

[Django]

#26997: crash on empty model permissions
-+
 Reporter:  hellpain |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  1.10
 Severity:  Release blocker  |   Resolution:
 Keywords:  permissions  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+
Description changed by hellpain:

Old description:

> While trying to port project to django 1.10 I found an error.
> If Meta of model has default_permissions = () django crashes on
> runserver, makemigrations and all other commands.
> Test project can is located
> https://github.com/hellpain/django_default_permissions_bug/blob/master/foo_app/models.py
>
> This bug is caused to refactored checks in contrib.auth

New description:

 While trying to port project to django 1.10 I found an error.
 If Meta of model has default_permissions = () django crashes on runserver,
 makemigrations and all other commands.
 Test project can is located at
 [https://github.com/hellpain/django_default_permissions_bug/]
 Example of corrupted model:
 
[https://github.com/hellpain/django_default_permissions_bug/blob/master/foo_app/models.py]

 This bug is caused to refactored checks in contrib.auth

 PR to fix bug: [https://github.com/django/django/pull/7007]

--

--
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.f5ebd352a8401a56a42030b048b844b1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26997: crash on empty model permissions

[Django]

#26997: crash on empty model permissions
-+
 Reporter:  hellpain |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  1.10
 Severity:  Release blocker  |   Resolution:
 Keywords:  permissions  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+

Comment (by charettes):

 [https://github.com/django/django/pull/7007 PR]

--
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.c7ff8b7f54e9846a5afb0fbf8713cba5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26979: Using an admin.RelatedOnlyFieldListFilter in admin does not working if a type of a field is ForeignKey and value to_field is not pk (in my case it is UUID).

[Django]

#26979: Using an admin.RelatedOnlyFieldListFilter in admin does not working if a
type of a field is ForeignKey and value to_field is not pk (in my case it
is UUID).
-+-
 Reporter:  setivolkylany|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.9
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  Admin, ForeignKey,   | Triage Stage:
  models |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * status:  new => closed
 * type:  Uncategorized => Bug
 * resolution:   => needsinfo


Comment:

 What's the error? I can't reproduce a crash in 1.10, 1.9, or 1.8 but maybe
 I didn't reproduce it correctly. If you can put together a simplified
 sample project without any third-party dependencies, that makes the issue
 much easier to triage.

--
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.26ce4150156675f4a841c7bbfa4a56f9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26996: Upgrade path for custom Context subclasses isn't documented

[Django]

#26996: Upgrade path for custom Context subclasses isn't documented
---+--
 Reporter:  pembo13|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.10
 Severity:  Normal |   Resolution:  wontfix
 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 pembo13):

 I understand. `render_to_response` used to take a `context_instance`, and
 there used to be documentation on subclassing `Context`. So while not
 directly mentioned, it was definitely possible to create a subclass of
 `Context` or `RequestContext` and use it with `render_to_response`.

 That's currently not possible with the current code, as of 1.10, which is
 fine. But it might be worth a note saying that explicitly.

--
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.e1275e2aadc0dfcc79341bf643b71758%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26974: Support for Hash indexes

[Django]

#26974: Support for Hash indexes
-+-
 Reporter:  akki |Owner:  akki
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  db-indexes   | Triage Stage:
 |  Someday/Maybe
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * stage:  Unreviewed => Someday/Maybe


Comment:

 Given the last comment, it seems prudent to have a discussion on the
 DevelopersMailingList about whether or not to implement this.

--
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/062.033a097995aa56f157817e473a8d3ae0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26983: Boolean filter "field__isnull=False" not working with ForeignKey with to_field

[Django]

#26983: Boolean filter "field__isnull=False" not working with ForeignKey with
to_field
-+-
 Reporter:  weidwonder   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  queryset | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * stage:  Accepted => Ready for checkin


--
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/068.d35bfbb5b7846780541f1a060963b0ab%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26997: crash on empty model permissions

[Django]

#26997: crash on empty model permissions
-+
 Reporter:  hellpain |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  1.10
 Severity:  Release blocker  |   Resolution:
 Keywords:  permissions  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+
Changes (by timgraham):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * severity:  Normal => Release blocker
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 Could you send a pull request to master and include a release note in
 docs/releases/1.10.1.txt?

--
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.3b3756b2c0fbd8008a6f1556d63ba0b8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26996: Upgrade path for custom Context subclasses isn't documented

[Django]

#26996: Upgrade path for custom Context subclasses isn't documented
---+--
 Reporter:  pembo13|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.10
 Severity:  Normal |   Resolution:  wontfix
 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 aaugustin):

 Like Tim, I'm not aware of any public APIs on the Context class that
 provide a useful extension point, so I don't know where to start to help
 you. You might want to explain why you were doing this. The
 DevelopersMailingList is likely a better forum for this discussion than
 this ticket.

--
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.83fcd3cca1e0a63c2b7a27bcb5bd68f7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26709: Add operation for creating database indexes and class based indexes

[Django]

#26709: Add operation for creating database indexes and class based indexes
-+
 Reporter:  akki |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  db-indexes   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Tim Graham ):

 In [changeset:"b92c6b7d5641e927145318adaaca1156ce26ddd2" b92c6b7]:
 {{{
 #!CommitTicketReference repository=""
 revision="b92c6b7d5641e927145318adaaca1156ce26ddd2"
 Refs #26709 -- Replaced Index.get_name() with set_name_with_model().

 This removes the dependency of the Index class on its 'model'
 attribute.
 }}}

--
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/062.5173d9ce73957c78756c08da05c574fd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26997: crash on empty model permissions

[Django]

#26997: crash on empty model permissions
--+
 Reporter:  hellpain  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  contrib.auth  |Version:  1.10
 Severity:  Normal| Resolution:
 Keywords:  permissions   |   Triage Stage:  Unreviewed
Has patch:  1 |  Easy pickings:  1
UI/UX:  0 |
--+
Changes (by hellpain):

 * Attachment "diff.txt" added.

 bug fix + tests

--
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.06b3eb3e229ddd22e33c84827cd4be3c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26997: crash on empty model permissions

[Django]

#26997: crash on empty model permissions
--+-
 Reporter:  hellpain  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  contrib.auth  |Version:  1.10
 Severity:  Normal|   Keywords:  permissions
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  1 |  UI/UX:  0
--+-
 While trying to port project to django 1.10 I found an error.
 If Meta of model has default_permissions = () django crashes on runserver,
 makemigrations and all other commands.
 Test project can is located
 
https://github.com/hellpain/django_default_permissions_bug/blob/master/foo_app/models.py

 This bug is caused to refactored checks in contrib.auth

--
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/051.f6c521220921c7b9095d48349fc02c5e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26995: Windows Error 10053 after changing database engine

[Django]

#26995: Windows Error 10053 after changing database engine
-+-
 Reporter:  SushantGahlot|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 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 timgraham):

 * status:  new => closed
 * needs_docs:   => 0
 * resolution:   => duplicate
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Comment:

 I guess this may be [https://bugs.python.org/issue14574 a problem in
 Python] instead of an issue with Django. If you can explain why Django is
 at fault, feel free to reopen. If you need help debugging, please see
 TicketClosingReasons/UseSupportChannels.

 See also #26072.

--
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.4ea5894362ec4903ad9c6d9aad23622b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26980: Make it easier to change what RemoteTestRunner is used

[Django]

#26980: Make it easier to change what RemoteTestRunner is used
-+-
 Reporter:  cjerdonek|Owner:  cjerdonek
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"ef92ed530e685ea022c172f1765279a54130bd6e" ef92ed53]:
 {{{
 #!CommitTicketReference repository=""
 revision="ef92ed530e685ea022c172f1765279a54130bd6e"
 Fixed #26980 -- Added ParallelTestSuite.runner_class to aid subclassing.
 }}}

--
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.60146b1afd15688bc2ca143ada808bf2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26996: Upgrade path for custom Context subclasses isn't documented

[Django]

#26996: Upgrade path for custom Context subclasses isn't documented
---+--
 Reporter:  pembo13|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.10
 Severity:  Normal |   Resolution:  wontfix
 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 timgraham):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => wontfix
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Unfortunately, we don't provide upgrade instructions for undocumented and
 untested use cases.

--
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.d2ac548f945b31ea0b3a428e6f76c2c7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26996: Upgrade path for custom Context subclasses isn't documented

[Django]

#26996: Upgrade path for custom Context subclasses isn't documented
---+
 Reporter:  pembo13|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.10
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 It used to be possible to pass a custom context instances to
 render_to_response. Now that's no longer possible, and there is no
 recommended upgrade path in the changelog or reference documentation.

--
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/050.2284803242eadc8588ccab47cb67ec36%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26995: Windows Error 10053 after changing database engine

[Django]

#26995: Windows Error 10053 after changing database engine
--+
 Reporter:  SushantGahlot |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.10
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 This particular error showed up after I changed database engine from
 SQLite3 to PostgreSQL-
 {{{
 [02/Aug/2016 21:19:20] "GET /api/delet/ HTTP/1.1" 404 6205
 [02/Aug/2016 21:19:25] "GET /api/delete/ HTTP/1.1" 200 7
 Traceback (most recent call last):
   File "c:\program files (x86)\python35-32\Lib\wsgiref\handlers.py", line
 138, in run
 self.finish_response()
   File "c:\program files (x86)\python35-32\Lib\wsgiref\handlers.py", line
 180, in finish_response
 self.write(data)
   File "c:\program files (x86)\python35-32\Lib\wsgiref\handlers.py", line
 274, in write
 self.send_headers()
   File "c:\program files (x86)\python35-32\Lib\wsgiref\handlers.py", line
 332, in send_headers
 self.send_preamble()
   File "c:\program files (x86)\python35-32\Lib\wsgiref\handlers.py", line
 255, in send_preamble
 ('Date: %s\r\n' % format_date_time(time.time())).encode('iso-8859-1')
   File "c:\program files (x86)\python35-32\Lib\wsgiref\handlers.py", line
 453, in _write
 self.stdout.write(data)
   File "c:\program files (x86)\python35-32\Lib\socket.py", line 593, in
 write
 return self._sock.send(b)
 ConnectionAbortedError: [WinError 10053] An established connection was
 aborted by the software in your host machine
 [02/Aug/2016 21:19:25] "GET /api/delete/ HTTP/1.1" 500 59
 
 Exception happened during processing of request from ('127.0.0.1', 2446)
 [02/Aug/2016 21:19:25] "GET /api/delete/ HTTP/1.1" 200 7
 Traceback (most recent call last):
   File "c:\program files (x86)\python35-32\Lib\wsgiref\handlers.py", line
 138, in run
 self.finish_response()
   File "c:\program files (x86)\python35-32\Lib\wsgiref\handlers.py", line
 180, in finish_response
 self.write(data)
   File "c:\program files (x86)\python35-32\Lib\wsgiref\handlers.py", line
 274, in write
 self.send_headers()
   File "c:\program files (x86)\python35-32\Lib\wsgiref\handlers.py", line
 332, in send_headers
 self.send_preamble()
   File "c:\program files (x86)\python35-32\Lib\wsgiref\handlers.py", line
 255, in send_preamble
 ('Date: %s\r\n' % format_date_time(time.time())).encode('iso-8859-1')
   File "c:\program files (x86)\python35-32\Lib\wsgiref\handlers.py", line
 453, in _write
 self.stdout.write(data)
   File "c:\program files (x86)\python35-32\Lib\socket.py", line 593, in
 write
 return self._sock.send(b)
 ConnectionAbortedError: [WinError 10053] An established connection was
 aborted by the software in your host machine

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "c:\program files (x86)\python35-32\Lib\wsgiref\handlers.py", line
 141, in run
 self.handle_error()
   File "C:\Users\sushant\Desktop\projects\drfapi\venv\lib\site-
 packages\django\core\servers\basehttp.py", line 92, in handle_error
 super(ServerHandler, self).handle_error()
   File "c:\program files (x86)\python35-32\Lib\wsgiref\handlers.py", line
 368, in handle_error
 self.finish_response()
   File "c:\program files (x86)\python35-32\Lib\wsgiref\handlers.py", line
 180, in finish_response
 self.write(data)
   File "c:\program files (x86)\python35-32\Lib\wsgiref\handlers.py", line
 274, in write
 self.send_headers()
   File "c:\program files (x86)\python35-32\Lib\wsgiref\handlers.py", line
 331, in send_headers
 if not self.origin_server or self.client_is_modern():
   File "c:\program files (x86)\python35-32\Lib\wsgiref\handlers.py", line
 344, in client_is_modern
 return self.environ['SERVER_PROTOCOL'].upper() != 'HTTP/0.9'
 TypeError: 'NoneType' object is not subscriptable

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "c:\program files (x86)\python35-32\Lib\socketserver.py", line 628,
 in process_request_thread
 self.finish_request(request, client_address)
   File "c:\program files (x86)\python35-32\Lib\socketserver.py", line 357,
 in finish_request
 self.RequestHandlerClass(request, client_address, self)
   File "C:\Users\sushant\Desktop\projects\drfapi\venv\lib\site-
 packages\django\core\servers\basehttp.py", line 99, in __init__
 super(WSGIRequestHandler, self).__init__(*args, **kwargs)
   File "c:\program files (x86)\python35-32\Lib\socketserver.py", line 684,
 in __init__
 self.handle()
   File "C:\Users\sushant\Desktop\projects\drfa

Re: [Django] #26983: Boolean filter "field__isnull=False" not working with ForeignKey with to_field

[Django]

#26983: Boolean filter "field__isnull=False" not working with ForeignKey with
to_field
-+-
 Reporter:  weidwonder   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  queryset | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/7006 PR] resulting of discussions
 with bmispelon on IRC.

--
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/068.a4b5b2ee7003b25b2f0ad3e0f66c5cc6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26988: User is_authenticated callable property is confusing to check

[Django]

#26988: User is_authenticated callable property is confusing to check
-+-
 Reporter:  marktranchant|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  1.10
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  user | Triage Stage:  Accepted
  is_authenticated property test |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"fa4b5c1b9360dc4c6abe913e86d3d36793d8826a" fa4b5c1b]:
 {{{
 #!CommitTicketReference repository=""
 revision="fa4b5c1b9360dc4c6abe913e86d3d36793d8826a"
 [1.10.x] Fixed #26988 -- Improved/clarified
 User.is_authenticated/anonymous compatibility.

 Thanks marktranchant for the report and review.

 Backport of 54afa960d1ee8c63635225a0f0a2489971b5aab5 from master
 }}}

--
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.070dabc2b2a3e62b16d8ab9de32e448c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26988: User is_authenticated callable property is confusing to check

[Django]

#26988: User is_authenticated callable property is confusing to check
-+-
 Reporter:  marktranchant|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  1.10
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  user | Triage Stage:  Accepted
  is_authenticated property test |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"54afa960d1ee8c63635225a0f0a2489971b5aab5" 54afa960]:
 {{{
 #!CommitTicketReference repository=""
 revision="54afa960d1ee8c63635225a0f0a2489971b5aab5"
 Fixed #26988 -- Improved/clarified User.is_authenticated/anonymous
 compatibility.

 Thanks marktranchant for the report and review.
 }}}

--
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.6b828c1f352c2f0c105563bbc314ce13%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26983: Boolean filter "field__isnull=False" not working with ForeignKey with to_field

[Django]

#26983: Boolean filter "field__isnull=False" not working with ForeignKey with
to_field
-+-
 Reporter:  weidwonder   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  queryset | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by charettes):

 Replying to [comment:5 MatthewWilkes]:
 > I don't believe that IsNull lookups should be converting their values to
 the type of the parent field, however the RelatedLookupMixin has useful
 looking code for ensuring that MultiColSource is handled correctly.
 >
 > Would the fix for this be as simple as:
 >
 > {{{
 > class RelatedIsNull(RelatedLookupMixin, IsNull):
 > def get_prep_lookup(self):
 > return self.rhs
 > }}}
 > ?

 `return super(RelatedLookupMixin, self).get_prep_lookup()` would be more
 appropriate.

--
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/068.ba3b74b0ba96115acda3f209d45c0447%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26983: Boolean filter "field__isnull=False" not working with ForeignKey with to_field

[Django]

#26983: Boolean filter "field__isnull=False" not working with ForeignKey with
to_field
-+-
 Reporter:  weidwonder   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  queryset | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by MatthewWilkes):

 I don't believe that IsNull lookups should be converting their values to
 the type of the parent field, however the RelatedLookupMixin has useful
 looking code for ensuring that MultiColSource is handled correctly.

 Would the fix for this be as simple as:

 {{{
 class RelatedIsNull(RelatedLookupMixin, IsNull):
 def get_prep_lookup(self):
 return self.rhs
 }}}
 ?

--
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/068.4afe20489af9ec7b1877117b4c87e6d5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26984: Data Migrations and auto_now

[Django]

#26984: Data Migrations and auto_now
-+--
 Reporter:  fizista  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Migrations   |  Version:  master
 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 charettes):

 Or maybe you are suggesting that `auto_now` and `auto_now_add` shouldn't
 be effective in data migrations (e.g. `RunPython`?).

 If that's the case I'm inclined to close this as ''wontfix'' since a lot
 of efforts are made to make sure models provided in data migrations behave
 exactly like normal models do.

--
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.de71da7145515266c5a6fb7264df1235%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26991: Check for SQL_AUTO_IS_NULL fails on special database connections

[Django]

#26991: Check for SQL_AUTO_IS_NULL fails on special database connections
-+-
 Reporter:  gerricom |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"11c5c3b8012328dfc0fbb78c758335c6e6054cc5" 11c5c3b8]:
 {{{
 #!CommitTicketReference repository=""
 revision="11c5c3b8012328dfc0fbb78c758335c6e6054cc5"
 [1.10.x] Fixed #26991 -- Fixed a crash in MySQL where SELECT
 @@SQL_AUTO_IS_NULL doesn't return a result.

 Backport of 431cbd115b9aac22a539682820742d9966237a84 from master
 }}}

--
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.a7c669e51aec62a2591e3e9d9017d976%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26984: Data Migrations and auto_now

[Django]

#26984: Data Migrations and auto_now
-+--
 Reporter:  fizista  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Migrations   |  Version:  master
 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 charettes):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Hi fizista,

 I'm not sure I understand your request.

 Using `auto_now` (just like any other `default` option) result in usage of
 `DEFAULT` in `ADD FIELD` operations which is required when adding `NOT
 NULL` fields (e.g. `DateTimeField(auto_now=True)`). What should be done
 when such a column is added if we were to drop support for `default`
 altogether?

--
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.3df72b37874fb164afa2a59857faeef8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26991: Check for SQL_AUTO_IS_NULL fails on special database connections

[Django]

#26991: Check for SQL_AUTO_IS_NULL fails on special database connections
-+-
 Reporter:  gerricom |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"d95c669c29a0403cd1098664f0ef863fae8b7c98" d95c669c]:
 {{{
 #!CommitTicketReference repository=""
 revision="d95c669c29a0403cd1098664f0ef863fae8b7c98"
 Fixed #26991 -- Fixed a crash in MySQL where SQL_AUTO_IS_NULL doesn't
 return a result.
 }}}

--
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.ea4b49c493a1716c5251c034ed5921ff%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26994: Remove blank line after template have been rendered

[Django]

#26994: Remove blank line after template have been rendered
-+-
 Reporter:  william1835  |Owner:
 Type:   |  william1835
  Cleanup/optimization   |   Status:  closed
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  template | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 Duplicate of #2594

--
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/069.509519720fda68dd0f01f929234a2276%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26994: Remove blank line after template have been rendered

[Django]

#26994: Remove blank line after template have been rendered
-+-
 Reporter:  william1835  |Owner:
 Type:   |  william1835
  Cleanup/optimization   |   Status:  assigned
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  template | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by william1835):

 * status:  new => assigned
 * needs_better_patch:   => 0
 * owner:  nobody => william1835
 * needs_tests:   => 0
 * needs_docs:   => 0


--
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/069.8478c1fd6f67ae8b2c078e2a0298e3c9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26994: Remove blank line after template have been rendered

[Django]

#26994: Remove blank line after template have been rendered
--+--
 Reporter:  william1835   |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Template system   |Version:  master
 Severity:  Normal|   Keywords:  template
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+--
 I have noticed that after a template in Django has been rendered, the
 lines where the template tags and filters have been used still remain. I
 know that this does not affect the outcome of the webpage as such, but it
 is of slight annoyance, and could potentially increase page loading times.

 Example (not realistic):
 This:
 {{{
 {% load customFilters %}
 
 
 
 }}}

 is rendered as:

 {{{

 
 
 
 }}}

 This can become noticeable in big files, especially when for loops are
 used.
 Thanks in advance

--
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/054.071d2f250748106c3bb6d03de3e46907%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26988: User is_authenticated callable property is confusing to check

[Django]

#26988: User is_authenticated callable property is confusing to check
-+-
 Reporter:  marktranchant|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  1.10
 Severity:  Release blocker  |   Resolution:
 Keywords:  user | Triage Stage:  Accepted
  is_authenticated property test |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by marktranchant):

 Thanks, looks like the best we can do for a transitional period. In your
 release notes update:

 Allowed User.is_authenticated() and User.is_anonymous() properties

 you should not include the brackets.

--
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.0a359212b7dd09967313eb15df542e83%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26988: User is_authenticated callable property is confusing to check

[Django]

#26988: User is_authenticated callable property is confusing to check
-+-
 Reporter:  marktranchant|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  1.10
 Severity:  Release blocker  |   Resolution:
 Keywords:  user | Triage Stage:  Accepted
  is_authenticated property test |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * has_patch:  0 => 1


--
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.4bd6066f41c288ab4c62a5e563f9c3cd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26993: Increase the length of the User model's last_name field to allow more of the world to use it

[Django]

#26993: Increase the length of the User model's last_name field to allow more of
the world to use it
-+-
 Reporter:  mbox |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * easy:  1 => 0
 * needs_docs:   => 0
 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Someday/Maybe


Comment:

 Bumping to Someday/Maybe until there's a consensus about what length to
 use (hopefully that discussion won't go much longer).

--
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/062.2dbf4abca1982debe528e0c031193e96%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26988: User is_authenticated callable property is confusing to check

[Django]

#26988: User is_authenticated callable property is confusing to check
-+-
 Reporter:  marktranchant|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  1.10
 Severity:  Release blocker  |   Resolution:
 Keywords:  user | Triage Stage:  Accepted
  is_authenticated property test |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * type:  Uncategorized => Cleanup/optimization
 * easy:  1 => 0
 * stage:  Unreviewed => Accepted


Comment:

 I think it's impossible to fix the `is` comparison, but we can fix `==`
 and `!=` as well as improve the release note.
 [https://github.com/django/django/pull/7005 PR].

--
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.5cee10efff05d175174e9ae212073218%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26991: Check for SQL_AUTO_IS_NULL fails on special database connections

[Django]

#26991: Check for SQL_AUTO_IS_NULL fails on special database connections
-+-
 Reporter:  gerricom |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by gerricom):

 Replying to [comment:1 timgraham]:
 > Does this [https://github.com/django/django/pull/7004 PR] work for you?
 I'm not sure if a test is feasible.

 This works perfectly nice. Thanks!

--
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.7ddfd66cf2e1ec5b146bd17a1a6a4746%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26993: Increase the length of the User model's last_name field to allow more of the world to use it

[Django]

#26993: Increase the length of the User model's last_name field to allow more of
the world to use it
--+
 Reporter:  mbox  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  contrib.auth  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+
 Large parts of the world have names that can easily exceed the current 30
 char limit - see discussion on Django-dev here:
 https://groups.google.com/forum/#!topic/django-developers/h98-oEi7z7g

 Conclusion from discussion that extending the last_name field to somewhere
 between 60 and 255 would be reasonable.

--
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.3d1105077993a8d74a65e4e50759201b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26992: On admin change view, exception raised from __unicode__ method of model related by fk is "hidden" and instead view without form shown

[Django]

#26992: On admin change view, exception raised from __unicode__ method of model
related by fk is "hidden" and instead view without form shown
-+-
 Reporter:  okrutny  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  change empty | Triage Stage:
  exception  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 I guess it might be the expected exception silencing of the
 [https://docs.djangoproject.com/en/stable/ref/templates/builtins/#include
 {% include %}] template tag. Could you try to do a little investigation to
 tell us exactly where the exception silencing is happening?

--
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.70588b4d29c6dfa4491e529e3c803cfb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26992: On admin change view, exception raised from __unicode__ method of model related by fk is "hidden" and instead view without form shown

[Django]

#26992: On admin change view, exception raised from __unicode__ method of model
related by fk is "hidden" and instead view without form shown
-+-
 Reporter:  okrutny  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  change empty | Triage Stage:
  exception  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by okrutny):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Old description:

> I have a model PolcardPayments which references Order by fk.
>

> {{{
> class PolcardPayments(models.Model):
> order = models.ForeignKey(Order, null=True)
> }}}
>

>
> {{{
> Order.__unicode__
> }}}
> was not correctly implemented, raising UnicodeEncodeError.
>
> When I entered change view of PolcardPayments as admin, form was not
> shown. I found in logs that UnicodeEncodeError is raised.

New description:

 I have a model PolcardPayments which references Order by fk.


 {{{
 class PolcardPayments(models.Model):
 order = models.ForeignKey(Order, null=True)
 }}}



 {{{
 Order.__unicode__
 }}}
 was not correctly implemented, raising UnicodeEncodeError.

 When I entered change view of PolcardPayments as admin, form was not
 shown. I found in logs that UnicodeEncodeError is raised.

 Expected behavour would be to raise 500 error and process same way as
 other such errors.

--

--
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.04864cc3220692169bd56a3fc48ae485%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26992: On admin change view, exception raised from __unicode__ method of model related by fk is "hidden" and instead view without form shown

[Django]

#26992: On admin change view, exception raised from __unicode__ method of model
related by fk is "hidden" and instead view without form shown
+
 Reporter:  okrutny |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  contrib.admin   |Version:  1.9
 Severity:  Normal  | Resolution:
 Keywords:  change empty exception  |   Triage Stage:  Unreviewed
Has patch:  0   |  Easy pickings:  0
UI/UX:  0   |
+
Changes (by okrutny):

 * Attachment "empty_change_view.png" added.

 empty change view

--
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.aacad324656747722ee72d3cea9af149%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26992: On admin change view, exception raised from __unicode__ method of model related by fk is "hidden" and instead view without form shown

[Django]

#26992: On admin change view, exception raised from __unicode__ method of model
related by fk is "hidden" and instead view without form shown
---+
 Reporter:  okrutny|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admin  |Version:  1.9
 Severity:  Normal |   Keywords:  change empty exception
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 I have a model PolcardPayments which references Order by fk.


 {{{
 class PolcardPayments(models.Model):
 order = models.ForeignKey(Order, null=True)
 }}}



 {{{
 Order.__unicode__
 }}}
 was not correctly implemented, raising UnicodeEncodeError.

 When I entered change view of PolcardPayments as admin, form was not
 shown. I found in logs that UnicodeEncodeError is raised.

--
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/050.48b72acd83cf4989c3791e7d8c3c56e6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26808: Support adding class based indexes from Meta class

[Django]

#26808: Support adding class based indexes from Meta class
-+-
 Reporter:  akki |Owner:  akki
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  db-indexes   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by edmorley):

 * cc: emorley@… (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/062.063ba0b834f366336e3e7374515b4560%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26983: Boolean filter "field__isnull=False" not working with ForeignKey with to_field (was: models.Manager query "filter(field__isnull=False)" not working in 1.10)

[Django]

#26983: Boolean filter "field__isnull=False" not working with ForeignKey with
to_field
-+-
 Reporter:  weidwonder   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  queryset | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

--
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/068.fd19fd1d66e3bbabaaf71584538300d2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26990: Support MySQL FULLTEXT INDEX in the model DDL

[Django]

#26990: Support MySQL FULLTEXT INDEX in the model DDL
-+-
 Reporter:  edmorley |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  mysql, fulltext, | Triage Stage:
  index  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by edmorley):

 Thank you, I've filed:
 https://github.com/adamchainz/django-mysql/issues/314

--
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.aaaec5918c95ad30eebb2abb0f676515%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26987: Document using .get() without args to return an object from a single-row queryset (was: doc: .get() without args is worth mentioning)

[Django]

#26987: Document using .get() without args to return an object from a single-row
queryset
--+
 Reporter:  Tuttle|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.10
 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
--+
Changes (by timgraham):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Accepted


--
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.7cb12e4345ace4ef75f7fc66dbaa959e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26990: Support MySQL FULLTEXT INDEX in the model DDL

[Django]

#26990: Support MySQL FULLTEXT INDEX in the model DDL
-+-
 Reporter:  edmorley |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  mysql, fulltext, | Triage Stage:
  index  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => wontfix
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 This seems better suited for a possible `contrib.mysql` package, however,
 I don't think it makes sense to add such an index if this is the only
 feature. We might reopen this at some later time if such a package
 developers in Django. Meanwhile, you could propose it in an external
 package such as [https://github.com/adamchainz/django-mysql/ django-
 mysql]. It likely needs to wait until more formal support for indexes is
 release in Django 1.11.

--
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.3561163e599795ca7951468042f70429%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26991: Check for SQL_AUTO_IS_NULL fails on special database connections

[Django]

#26991: Check for SQL_AUTO_IS_NULL fails on special database connections
-+-
 Reporter:  gerricom |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * severity:  Normal => Release blocker
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0
 * has_patch:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 Does this [https://github.com/django/django/pull/7004 PR] work for you?
 I'm not sure if a test is feasible.

--
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.7441cb03866d47789ecf2a7b066a7bbc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21295: Add on_update support

[Django]

#21295: Add on_update support
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by edmorley):

 * cc: emorley@… (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/066.d281ef7876953d2c51b61578b9d34032%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21961: Add support for database-level cascading options

[Django]

#21961: Add support for database-level cascading options
-+-
 Reporter:  Xof  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 edmorley):

 * cc: emorley@… (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.43711b4db456239c4409873b03034731%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26989: Provide a way of specifying ON DELETE and On UPDATE properties in model DDL

[Django]

#26989: Provide a way of specifying ON DELETE and On UPDATE properties in model 
DDL
-+-
 Reporter:  jgraham  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 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 timgraham):

 * status:  new => closed
 * resolution:   => duplicate
 * component:  Uncategorized => Database layer (models, ORM)
 * type:  Uncategorized => New feature


Comment:

 Duplicate of #21961 (ON DELETE) and #21295 (ON UPDATE).

--
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.50e44f66554286b55484e170d949492e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26985: Document restrictions on fields that can be referenced by ForeignKey.to_field

[Django]

#26985: Document restrictions on fields that can be referenced by
ForeignKey.to_field
--+
 Reporter:  bmispelon |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.10
 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 timgraham):

 * stage:  Unreviewed => Accepted


--
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.dcc51f7e9694ddc8896142a07f7c041a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #19527: Allow QuerySet.bulk_create() to set the primary key of its objects

[Django]

#19527: Allow QuerySet.bulk_create() to set the primary key of its objects
-+-
 Reporter:  Tuttle   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle   | Triage Stage:  Accepted
  QuerySet.bulk_create   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tuttle):

 I'm sorry, Tim.

--
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.81bb506ccb2bf6c641b7bfc2998d6954%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #19527: Allow QuerySet.bulk_create() to set the primary key of its objects

[Django]

#19527: Allow QuerySet.bulk_create() to set the primary key of its objects
-+-
 Reporter:  Tuttle   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle   | Triage Stage:  Accepted
  QuerySet.bulk_create   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 Per comment:33, "(leaving the ticket open for the Oracle implementation)".

--
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.84d36341da92417d06f16f2d7a498195%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26986: `force_login` requires `user.is_active` in 1.10

[Django]

#26986: `force_login` requires `user.is_active` in 1.10
--+
 Reporter:  Tordek|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by timgraham):

 I don't understand the report. Can you give example code to show the
 behavior change? The release note is referring to the removal of the
 
[https://github.com/django/django/commit/107165c4b04f4e5a830a60b6c66b2e5d8fb1d242
 #diff-97160f50594424a40f2621d5a3c581ccL602 user.is_active check in
 login()]. As far as I see, `force_login()` isn't affected by that.

--
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.9774ffeb4e80e2a5f20605c5b5461cda%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25684: Runserver doesn't use `LOGGING` configuration

[Django]

#25684: Runserver doesn't use `LOGGING` configuration
---+
 Reporter:  fcurella   |Owner:  fcurella
 Type:  New feature|   Status:  closed
Component:  Error reporting|  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords:  runserver logging  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by timgraham):

 New ticket with steps to reproduce.

--
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.21dddf133fc7ff2c87fb8b4fd57caa2f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25684: Runserver doesn't use `LOGGING` configuration

[Django]

#25684: Runserver doesn't use `LOGGING` configuration
---+
 Reporter:  fcurella   |Owner:  fcurella
 Type:  New feature|   Status:  closed
Component:  Error reporting|  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords:  runserver logging  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by marktranchant):

 Replying to [comment:38 Tim Graham ]:
 > In [changeset:"0bc5cd628042bf0a44df60a93085a4f991a84dfb" 0bc5cd62]:
 > {{{
 > #!CommitTicketReference repository=""
 revision="0bc5cd628042bf0a44df60a93085a4f991a84dfb"
 > Fixed #25684 -- Made runserver use logging for request/response output.
 >
 > Thanks andreif for the contributing to the patch.
 > }}}

 Since upgrading to 1.10, my test suite (from {{{manage.py test}}}) now
 kicks up this error from {{{ServerFormatter.format()}}} method. Doesn't
 affect my tests. Not sure how to flag this error: here, or new ticket?

 {{{
 Traceback (most recent call last):
   File "/usr/lib/python2.7/logging/__init__.py", line 861, in emit
 msg = self.format(record)
   File "/usr/lib/python2.7/logging/__init__.py", line 734, in format
 return fmt.format(record)
   File "/home/my-venv/lib/python2.7/site-packages/django/utils/log.py",
 line 173, in format
 if args[1][0] == '2':
 IndexError: tuple index out of range
 Logged from file basehttp.py, line 85
 }}}

--
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.c7dc5b804aa9ddbb74857bfa37385688%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26991: Check for SQL_AUTO_IS_NULL fails on special database connections

[Django]

#26991: Check for SQL_AUTO_IS_NULL fails on special database connections
--+
 Reporter:  gerricom  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.10
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 With #24675 a check for SQL_AUTO_IS_NULL is introduced in initializing a
 MySQL database connection.

 I have some special use case here in which this causes an error. I'm
 connecting via MySQL to an sphinxsearch database. It basically uses the
 MySQL query language but has some special features.
 `cursor.execute('SELECT @@SQL_AUTO_IS_NULL')` returns `None` and therefore
 `is_sql_auto_is_null_enabled` in `features.py` is failing.

 I think a simple check if `cursor.fetchone()` has a result would solve the
 problem.

--
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/051.dfdeb471f29a8fdcd7c1341254ab89b3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26990: Support MySQL FULLTEXT INDEX in the model DDL

[Django]

#26990: Support MySQL FULLTEXT INDEX in the model DDL
--+
 Reporter:  edmorley  |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  Database layer (models, ORM)  |Version:  master
 Severity:  Normal|   Keywords:  mysql,
  |  fulltext, index
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Whilst there is ticket #3254 filed for general full text search support,
 it's regarding multiple DB types and primarily about adding support for
 searching, rather than creating indexes. As such, I think it's easier to
 break this piece out to a new ticket.

 In MySQL 5.6 support was added to InnoDB for full text indexes:
 https://dev.mysql.com/doc/refman/5.6/en/innodb-fulltext-index.html

 Currently we have to create these via a migration like:

 {{{
 migrations.RunSQL(
 sql='CREATE FULLTEXT INDEX `idx_description` on foo(`description`);',
 reverse_sql='ALTER TABLE foo DROP INDEX idx_description',
 ),
 }}}

 It would be ideal to be able to define them via the model DDL instead, so
 the full DB state can be recreated from the model.

--
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/051.b2906a3dcbb71602a1402c6d0654f0fc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26988: User is_authenticated callable property is confusing to check

[Django]

#26988: User is_authenticated callable property is confusing to check
-+-
 Reporter:  marktranchant|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  contrib.auth |  Version:  1.10
 Severity:  Release blocker  |   Resolution:
 Keywords:  user | Triage Stage:
  is_authenticated property test |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Description changed by marktranchant:

Old description:

> Just upgraded to 1.10, converted all {{{is_authenticated()}}} methods
> into {{{is_authenticated}}} properties as per the
> [https://docs.djangoproject.com/en/1.10/releases/1.10/#using-user-is-
> authenticated-and-user-is-anonymous-as-methods Release Notes] and a test
> in my test suite failed.
>
> It turns out I was checking for a logged in user with {{{if
> request.user.is_authenticated is False:}}}, but the
> {{{is_authenticated}}} property is actually a {{{CallableBool}}} which
> cannot be tested with {{== False}}, {{is False}}, {{== True}} or {{is
> True}}.
>
> Checking this property only gives logical results with direct {{{if
> user.is_authenticated}}} or {{{if not user.is_authenticated}}}. This is
> very misleading and non-intuitive behaviour (at odds with
> [https://www.python.org/dev/peps/pep-0008/#programming-recommendations
> PEP8 (bottom of linked section)] and should be fixed or strongly called
> out in the documentation. Example:
>
> {{{
> In [1]: from django.contrib.auth.models import AnonymousUser,
> AbstractBaseUser
>
> In [2]: a = AnonymousUser()
>
> In [3]: b = AbstractBaseUser()
>
> In [4]: a.is_authenticated
> Out[4]: CallableBool(False)
>
> In [5]: b.is_authenticated
> Out[5]: CallableBool(True)
>
> In [6]: a.is_authenticated is False
> Out[6]: False
>
> In [7]: a.is_authenticated == False
> Out[7]: False
>
> In [8]: not a.is_authenticated
> Out[8]: True
>
> In [9]: not b.is_authenticated
> Out[9]: False
>
> In [10]: b.is_authenticated == False
> Out[10]: False
>
> In [11]: b.is_authenticated == True
> Out[11]: False
> }}}

New description:

 Just upgraded to 1.10, converted all {{{is_authenticated()}}} methods into
 {{{is_authenticated}}} properties as per the
 [https://docs.djangoproject.com/en/1.10/releases/1.10/#using-user-is-
 authenticated-and-user-is-anonymous-as-methods Release Notes] and a test
 in my test suite failed.

 It turns out I was checking for a logged in user with {{{if
 request.user.is_authenticated is False:}}}, but the {{{is_authenticated}}}
 property is actually a {{{CallableBool}}} which cannot be tested with {{==
 False}}, {{is False}}, {{== True}} or {{is True}}.

 Checking this property only gives logical results with direct {{{if
 user.is_authenticated}}} or {{{if not user.is_authenticated}}}. This is
 very misleading and non-intuitive behaviour (at odds with
 [https://www.python.org/dev/peps/pep-0008/#programming-recommendations
 PEP8 (bottom of linked section)]) and should be fixed or strongly called
 out in the documentation. Example:

 {{{
 In [1]: from django.contrib.auth.models import AnonymousUser,
 AbstractBaseUser

 In [2]: a = AnonymousUser()

 In [3]: b = AbstractBaseUser()

 In [4]: a.is_authenticated
 Out[4]: CallableBool(False)

 In [5]: b.is_authenticated
 Out[5]: CallableBool(True)

 In [6]: a.is_authenticated is False
 Out[6]: False

 In [7]: a.is_authenticated == False
 Out[7]: False

 In [8]: not a.is_authenticated
 Out[8]: True

 In [9]: not b.is_authenticated
 Out[9]: False

 In [10]: b.is_authenticated == False
 Out[10]: False

 In [11]: b.is_authenticated == True
 Out[11]: False
 }}}

--

--
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.827ed8406c1a29646f2792e00a95fad0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26988: User is_authenticated callable property is confusing to check

[Django]

#26988: User is_authenticated callable property is confusing to check
-+-
 Reporter:  marktranchant|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  contrib.auth |  Version:  1.10
 Severity:  Release blocker  |   Resolution:
 Keywords:  user | Triage Stage:
  is_authenticated property test |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by marktranchant):

 * easy:  0 => 1


Old description:

> Just upgraded to 1.10, converted all {{{ is_authenticated() }}} methods
> into {{{ is_authenticated }}} properties as per the
> [https://docs.djangoproject.com/en/1.10/releases/1.10/#using-user-is-
> authenticated-and-user-is-anonymous-as-methods Release Notes] and a test
> in my test suite failed.
>
> It turns out I was checking for a logged in user with {{{ if
> request.user.is_authenticated is False: }}}, but the {{{ is_authenticated
> }}} property is actually a {{{ CallableBool() }}} so is not False under
> any circumstances.
>
> Checking this property only gives logical results with direct {{{ if
> user.is_authenticated }}} or {{{ if not user.is_authenticated }}}. This
> is very misleading and non-intuitive behaviour and should be fixed or
> strongly called out in the documentation. Example:
>
> {{{
> In [1]: from django.contrib.auth.models import AnonymousUser,
> AbstractBaseUser
>
> In [2]: a = AnonymousUser()
>
> In [3]: b = AbstractBaseUser()
>
> In [4]: a.is_authenticated
> Out[4]: CallableBool(False)
>
> In [5]: b.is_authenticated
> Out[5]: CallableBool(True)
>
> In [6]: a.is_authenticated is False
> Out[6]: False
>
> In [7]: a.is_authenticated == False
> Out[7]: False
>
> In [8]: not a.is_authenticated
> Out[8]: True
>
> In [9]: not b.is_authenticated
> Out[9]: False
>
> In [10]: b.is_authenticated == False
> Out[10]: False
>
> In [11]: b.is_authenticated == True
> Out[11]: False
> }}}

New description:

 Just upgraded to 1.10, converted all {{{is_authenticated()}}} methods into
 {{{is_authenticated}}} properties as per the
 [https://docs.djangoproject.com/en/1.10/releases/1.10/#using-user-is-
 authenticated-and-user-is-anonymous-as-methods Release Notes] and a test
 in my test suite failed.

 It turns out I was checking for a logged in user with {{{if
 request.user.is_authenticated is False:}}}, but the {{{is_authenticated}}}
 property is actually a {{{CallableBool}}} which cannot be tested with {{==
 False}}, {{is False}}, {{== True}} or {{is True}}.

 Checking this property only gives logical results with direct {{{if
 user.is_authenticated}}} or {{{if not user.is_authenticated}}}. This is
 very misleading and non-intuitive behaviour (at odds with
 [https://www.python.org/dev/peps/pep-0008/#programming-recommendations
 PEP8 (bottom of linked section)] and should be fixed or strongly called
 out in the documentation. Example:

 {{{
 In [1]: from django.contrib.auth.models import AnonymousUser,
 AbstractBaseUser

 In [2]: a = AnonymousUser()

 In [3]: b = AbstractBaseUser()

 In [4]: a.is_authenticated
 Out[4]: CallableBool(False)

 In [5]: b.is_authenticated
 Out[5]: CallableBool(True)

 In [6]: a.is_authenticated is False
 Out[6]: False

 In [7]: a.is_authenticated == False
 Out[7]: False

 In [8]: not a.is_authenticated
 Out[8]: True

 In [9]: not b.is_authenticated
 Out[9]: False

 In [10]: b.is_authenticated == False
 Out[10]: False

 In [11]: b.is_authenticated == True
 Out[11]: False
 }}}

--

--
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.464736b8502636621ab6ebf11cacb3b6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26989: Provide a way of specifying ON DELETE and On UPDATE properties in model DDL

[Django]

#26989: Provide a way of specifying ON DELETE and On UPDATE properties in model 
DDL
---+--
 Reporter:  jgraham|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.10
 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 edmorley):

 * cc: emorley@… (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


--
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.caeb8883b1d1164c20447d71c4e151ff%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26989: Provide a way of specifying ON DELETE and On UPDATE properties in model DDL

[Django]

#26989: Provide a way of specifying ON DELETE and On UPDATE properties in model 
DDL
---+
 Reporter:  jgraham|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.10
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 I have read [1] and I understand that in general Django has good reasons
 for emulating ON DELETE behaviour such as ON DELETE CASCADE. However we
 have a case where the database native support is sufficient to meet our
 needs, and will provide a performance win on a problematically-slow bulk
 delete operation. It is possible for us to configure this e.g. by using a
 migration with a RawSQL operation, but if we take this approach we no
 longer have the ability to recreate the full database state from the
 django model. Therefore it would be helpful if there was a way to specify
 these properties in the model, even if django does not rely on them during
 normal operations.

 This would provide feature parity with SQLAlchemy in this area, which also
 uses emulated cascading behaviour by default, but allows specifying the
 schema-level constructs to be specified in the DDL [2].

 [1] https://groups.google.com/forum/#%21topic/django-
 developers/FGDanrS9vlw
 [2] http://docs.sqlalchemy.org/en/rel_1_0/orm/cascades.html#delete

--
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/050.0d6a9620db3e568eb5762e4aa41feff5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26986: `force_login` requires `user.is_active` in 1.10

[Django]

#26986: `force_login` requires `user.is_active` in 1.10
--+
 Reporter:  Tordek|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by bmispelon):

 * needs_better_patch:   => 0
 * component:  Testing framework => Documentation
 * needs_tests:   => 0
 * needs_docs:   => 0
 * has_patch:  0 => 1
 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 Mentioning `force_login` in the release note would be nice, if only for
 grepping.

 There's a pull request at https://github.com/django/django/pull/7003.

--
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.cda89ed9a973bf486ed846c1f4fac88e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26988: User is_authenticated callable property is confusing to check (was: User is_authenticated callable property confusing if used with "is False")

[Django]

#26988: User is_authenticated callable property is confusing to check
-+-
 Reporter:  marktranchant|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  contrib.auth |  Version:  1.10
 Severity:  Release blocker  |   Resolution:
 Keywords:  user | Triage Stage:
  is_authenticated property test |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by marktranchant):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * needs_tests:   => 0


--
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.a642aa98f90de1a464f056dd97e70603%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26988: User is_authenticated callable property confusing if used with "is False"

[Django]

#26988: User is_authenticated callable property confusing if used with "is 
False"
-+-
 Reporter:   |  Owner:  nobody
  marktranchant  |
 Type:   | Status:  new
  Uncategorized  |
Component:   |Version:  1.10
  contrib.auth   |
 Severity:  Release  |   Keywords:  user is_authenticated property test
  blocker|
 Triage Stage:   |  Has patch:  0
  Unreviewed |
Easy pickings:  0|  UI/UX:  0
-+-
 Just upgraded to 1.10, converted all {{{ is_authenticated() }}} methods
 into {{{ is_authenticated }}} properties as per the
 [https://docs.djangoproject.com/en/1.10/releases/1.10/#using-user-is-
 authenticated-and-user-is-anonymous-as-methods Release Notes] and a test
 in my test suite failed.

 It turns out I was checking for a logged in user with {{{ if
 request.user.is_authenticated is False: }}}, but the {{{ is_authenticated
 }}} property is actually a {{{ CallableBool() }}} so is not False under
 any circumstances.

 Checking this property only gives logical results with direct {{{ if
 user.is_authenticated }}} or {{{ if not user.is_authenticated }}}. This is
 very misleading and non-intuitive behaviour and should be fixed or
 strongly called out in the documentation. Example:

 {{{
 In [1]: from django.contrib.auth.models import AnonymousUser,
 AbstractBaseUser

 In [2]: a = AnonymousUser()

 In [3]: b = AbstractBaseUser()

 In [4]: a.is_authenticated
 Out[4]: CallableBool(False)

 In [5]: b.is_authenticated
 Out[5]: CallableBool(True)

 In [6]: a.is_authenticated is False
 Out[6]: False

 In [7]: a.is_authenticated == False
 Out[7]: False

 In [8]: not a.is_authenticated
 Out[8]: True

 In [9]: not b.is_authenticated
 Out[9]: False

 In [10]: b.is_authenticated == False
 Out[10]: False

 In [11]: b.is_authenticated == True
 Out[11]: False
 }}}

--
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/056.8a7e95f6a904530cabbe316a1ff5562a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26981: Support passing custom kwargs to DiscoverRunner's test runner

[Django]

#26981: Support passing custom kwargs to DiscoverRunner's test runner
---+--
 Reporter:  cjerdonek  |Owner:  cjerdonek
 Type:  Uncategorized  |   Status:  assigned
Component:  Testing framework  |  Version:  master
 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 cjerdonek):

 I started working on this in branch
 [https://github.com/cjerdonek/django/tree/ticket_26981 ticket_26981] of my
 GitHub repo.

--
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.1f81fd5782c9447054d48ff399b03899%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.