date:20190404

Re: [Django] #1891: ForeignKey with m2m filter can duplicate foreign model entries in ModelForm/ModelChoiceField

2019-04-04 Thread Django

#1891: ForeignKey with m2m filter can duplicate foreign model entries in
ModelForm/ModelChoiceField
-+-
 Reporter:  mattimustang@…   |Owner:  Chris
 |  Wilson
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:
  (models, ORM)  |
 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
-+-

Comment (by Josh):

 Can we add an optional keyword argument to conditionally apply the
 DISTINCT select? This just bit me on a production app.

 Maybe something like:

 {{{
 account_manager = models.ForeignKey(
 User,
 limit_choices_to=Q(groups__name='Sales') | Q(groups__name='Admin'),
 limit_choices_distinct=True,  # default 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/080.af03e412fa4d97097fef71be2e0006bf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30332: Postgres ordering ARRAY_AGG and STRING_AGG do not support expression.

2019-04-04 Thread Django

#30332: Postgres ordering ARRAY_AGG and STRING_AGG do not support expression.
-+-
 Reporter:  Simone Pellizzari|Owner:  Simone
 |  Pellizzari
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgres string_agg  | Triage Stage:
  array_agg ordering order by|  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simone Pellizzari):

 * status:  new => assigned


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

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

Re: [Django] #30332: Postgres ordering ARRAY_AGG and STRING_AGG do not support expression.

2019-04-04 Thread Django

#30332: Postgres ordering ARRAY_AGG and STRING_AGG do not support expression.
-+-
 Reporter:  Simone Pellizzari|Owner:  Simone
 |  Pellizzari
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgres string_agg  | Triage Stage:
  array_agg ordering order by|  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simone Pellizzari):

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


Comment:

 Ahem, just wanted to marked as resolved by linked pull request...didn't
 really want to close :-)

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

Re: [Django] #30332: Postgres ordering ARRAY_AGG and STRING_AGG do not support expression.

2019-04-04 Thread Django

#30332: Postgres ordering ARRAY_AGG and STRING_AGG do not support expression.
-+-
 Reporter:  simone6021   |Owner:
 |  simone6021
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  postgres string_agg  | Triage Stage:
  array_agg ordering order by|  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by simone6021:

Old description:

> I found that if you pass and expression as an ordering argument
> (introduced in
> https://github.com/django/django/commit/96199e562dcc409ab4bdc2b2146fa7cf73c7c5fe)
> an {{{ IndexError: tuple index out of range }}} exception will be thrown
> when the query is executed.
>
> This is caused by simply ignoring {{{ sql_params }}} returned from {{{
> as_sql }}} elements contained in passed {{{ ordering }}} argument.

New description:

 I found that if you pass and expression as an ordering argument
 (introduced in
 
https://github.com/django/django/commit/96199e562dcc409ab4bdc2b2146fa7cf73c7c5fe)
 an {{{ IndexError: tuple index out of range }}} exception will be thrown
 when the query is executed.

 This is caused by simply ignoring {{{ sql_params }}} returned from {{{
 as_sql }}} calls on expressions contained built from {{{ ordering }}}
 argument.

--

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

Re: [Django] #30332: Postgres ordering ARRAY_AGG and STRING_AGG do not support expression.

2019-04-04 Thread Django

#30332: Postgres ordering ARRAY_AGG and STRING_AGG do not support expression.
-+-
 Reporter:  simone6021   |Owner:
 |  simone6021
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgres string_agg  | Triage Stage:
  array_agg ordering order by|  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by simone6021):

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


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

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

Re: [Django] #30332: Postgres ordering ARRAY_AGG and STRING_AGG do not support expression.

2019-04-04 Thread Django

#30332: Postgres ordering ARRAY_AGG and STRING_AGG do not support expression.
-+-
 Reporter:  simone6021   |Owner:
 |  simone6021
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  postgres string_agg  | Triage Stage:
  array_agg ordering order by|  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by simone6021):

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


Comment:

 See https://github.com/django/django/pull/11172

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

[Django] #30333: hash in model is None when eq is defined

2019-04-04 Thread Django

#30333: __hash__ in model is None when __eq__ is defined
-+-
   Reporter:  akjanik|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  2.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 In my model, that inherits directly from `models.Model`, I defined my own
 `__eq__`:
 {{{
 class Meta:
 ordering = ('pk', )

 def __eq__(self, other):
 return self.as_data() == other.as_data()
 }}}
 What was strange, when updating to `2.2`, classes like above (and
 instances) do not have `__hash__` defined anymore.
 {{{
 >>> from myapp.account.models import Address
 >>> Address.__hash__ is None
 True
 >>> import django
 >>> django.VERSION
 (2, 2, 0, 'final', 0)
 }}}
 while it was certainly present in `2.1`

 {{{
 >>> from myapp.account.models import Address
 >>> Address.__hash__
 
 >>> import django
 >>> django.VERSION
 (2, 1, 8, 'final', 0)
 }}}

 I am not sure if it is intended, as I did not find (or maybe missed)
 mentions about it in 2.2 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/050.3d925d3d3565dc7183541701933f3e31%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30332: Postgres ordering ARRAY_AGG and STRING_AGG do not support expression.

2019-04-04 Thread Django

#30332: Postgres ordering ARRAY_AGG and STRING_AGG do not support expression.
-+-
 Reporter:  simone6021   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgres string_agg  | Triage Stage:
  array_agg ordering order by|  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by simone6021:

Old description:

> I found that if you pass and expression as an ordering argument an {{{
> IndexError: tuple index out of range }}} exception will be thrown when
> the query is executed.
>
> This is caused by simply ignoring {{{ sql_params }}} returned from {{{
> as_sql }}} elements contained in passed {{{ ordering }}} argument.

New description:

 I found that if you pass and expression as an ordering argument
 (introduced in
 
https://github.com/django/django/commit/96199e562dcc409ab4bdc2b2146fa7cf73c7c5fe)
 an {{{ IndexError: tuple index out of range }}} exception will be thrown
 when the query is executed.

 This is caused by simply ignoring {{{ sql_params }}} returned from {{{
 as_sql }}} elements contained in passed {{{ ordering }}} argument.

--

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

[Django] #30332: Postgres ordering ARRAY_AGG and STRING_AGG do not support expression.

2019-04-04 Thread Django

#30332: Postgres ordering ARRAY_AGG and STRING_AGG do not support expression.
-+-
   Reporter: |  Owner:  nobody
  simone6021 |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  2.2
  layer (models, ORM)|   Keywords:  postgres string_agg
   Severity:  Normal |  array_agg ordering order by
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I found that if you pass and expression as an ordering argument an {{{
 IndexError: tuple index out of range }}} exception will be thrown when the
 query is executed.

 This is caused by simply ignoring {{{ sql_params }}} returned from {{{
 as_sql }}} elements contained in passed {{{ ordering }}} argument.

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

Re: [Django] #30309: Remove hasattr reference in One-to-One documentation example

2019-04-04 Thread Django

Comment (by Simon Charette):

FWIW this scenario can also happen when using
`on_delete=models.DO_NOTHING, db_constraint=False` and an attempt is made
to access a remote object that has been deleted.

I'd be in favor of making `ForwardManyToOneDescriptor.get_object` raise
`self.RelatedObjectDoesNotExist` as the current code clearly doesn't take
`db_constraint=False` into account based on

[https://github.com/django/django/blob/755673e1bca7edb6bee7a958f40d9ae54d85d44c/django/db/models/fields/related_descriptors.py#L144
the heuristic comment 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.38c976170be8fb703658822bd078f3f4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30323: Django 2.2 autoreloader is failing intermittently (not using watchman)

2019-04-04 Thread Django

#30323: Django 2.2 autoreloader is failing intermittently (not using watchman)
-+--
 Reporter:  Mark Chackerian  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Uncategorized|  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:  autoreloader | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by Sammie S. Taunton):

 * cc: Sammie S. Taunton (added)


Comment:

 Not sure if this will help you but I also faced this issue when using
 PyCharm. I dug down and found that by default PyCharm has an option:
 "Preserve file timestamps" on save. Once I unchecked that box, every file
 update caused watchman to reload. Either way, your original explanation is
 exactly what was happening to me too.

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

Re: [Django] #30331: Add support for psycopg2 2.8+. (was: Add suppor for psycopg2 2.8+.)

2019-04-04 Thread Django

#30331: Add support for psycopg2 2.8+.
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 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
-+-

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

Re: [Django] #30331: Add suppor for psycopg2 2.8+. (was: Add suppor for Psycopg 2.8+.)

2019-04-04 Thread Django

#30331: Add suppor for psycopg2 2.8+.
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 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 felixxm):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/11171 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/065.72e273550858894ec9f6f81c565f0db5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30331: Add suppor for Psycopg 2.8+.

2019-04-04 Thread Django

#30331: Add suppor for Psycopg 2.8+.
-+-
   Reporter:  felixxm|  Owner:  felixxm
   Type: | Status:  assigned
  Cleanup/optimization   |
  Component:  Database   |Version:  2.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Database introspection crashes with Psycopg 2.8+ due to this change
 {{{
 Changed in version 2.8: columns descriptions are instances of Column,
 exposing extra attributes.
 }}}
 in the `cursor.description` (see
 [http://initd.org/psycopg/docs/cursor.html#cursor.description
 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.97e21d76b5f514f14bc9561e6dcb8c9d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30330: delete() on instances of models without any dependencies doesn't clear PKs.

2019-04-04 Thread Django

#30330: delete() on instances of models without any dependencies doesn't clear 
PKs.
-+-
 Reporter:  Artui|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  delete, pk   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Florian Apolloner):

 I cannot test that now, but could it we that
 
https://github.com/django/django/commit/bc7dd8490b882b2cefdc7faf431dc64c532b79c9
 #diff-d426bf684ef79a85e978b039279b52ccR277 evaluates the instances
 generator and then
 
https://github.com/django/django/commit/bc7dd8490b882b2cefdc7faf431dc64c532b79c9
 #diff-d426bf684ef79a85e978b039279b52ccR285 fails?

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

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

Re: [Django] #30330: delete() on instances of models without any dependencies doesn't clear PKs.

2019-04-04 Thread Django

#30330: delete() on instances of models without any dependencies doesn't clear 
PKs.
-+-
 Reporter:  Artui|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  delete, pk   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * Attachment "test-30330.diff" added.

 Regression test.

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

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

Re: [Django] #30330: delete() on instances of models without any dependencies doesn't clear PKs. (was: Deletion isn't updating model)

2019-04-04 Thread Django

#30330: delete() on instances of models without any dependencies doesn't clear 
PKs.
-+-
 Reporter:  Artui|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  delete, pk   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * cc: Florian Apolloner (added)
 * stage:  Unreviewed => Accepted
 * severity:  Normal => Release blocker


Comment:

 Reproduced at 1ffddfc233e2d5139cc6ec31a4ec6ef70b10f87f.

 Regression in bc7dd8490b882b2cefdc7faf431dc64c532b79c9.

 Thanks for the report.

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

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

Re: [Django] #30329: ImproperlyConfigured exceptions should be raised immediately. (was: Make error message clearer when installed SQLite version is too old.)

2019-04-04 Thread Django

#30329: ImproperlyConfigured exceptions should be raised immediately.
-+
 Reporter:  Alasdair Nicol   |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Error reporting  |  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
-+
Description changed by felixxm:

Old description:

> When an older version of sqlite is installed, the final line of the
> traceback is unrelated.
>
> {{{
> raise LookupError(message)
> LookupError: No installed app with label 'admin'.
> }}}
>
> If you look further up the traceback, you can see what the problem is,
> but this can be tricky for newer users.
>
> {{{
> raise ImproperlyConfigured('SQLite 3.8.3 or later is required (found
> %s).' % Database.sqlite_version)
> django.core.exceptions.ImproperlyConfigured: SQLite 3.8.3 or later is
> required (found 3.7.17).
> }}}
>
> I think that if we made the error message clearer it would be helpful for
> new users. Perhaps we could do this by checking the sqlite version in a
> system check, or maybe there's a better approach.
>
> Related Stack Overflow question:
> https://stackoverflow.com/questions/55512244/no-installed-app-with-label-
> admin-in-empty-django-2-2-project/

New description:

 When an older version of sqlite is installed, the final line of the
 traceback is unrelated.

 {{{
 raise LookupError(message)
 LookupError: No installed app with label 'admin'.
 }}}

 If you look further up the traceback, you can see what the problem is, but
 this can be tricky for newer users.

 {{{
 raise ImproperlyConfigured('SQLite 3.8.3 or later is required (found
 %s).' % Database.sqlite_version)
 django.core.exceptions.ImproperlyConfigured: SQLite 3.8.3 or later is
 required (found 3.7.17).
 }}}

 I think that if we made the error message clearer it would be helpful for
 new users. Perhaps we could do this by checking the sqlite version in a
 system check, or maybe there's a better approach.

 Related Stack Overflow question:
 https://stackoverflow.com/questions/55512244/no-installed-app-with-label-
 admin-in-empty-django-2-2-project/


 See
 
[https://github.com/django/django/blob/755673e1bca7edb6bee7a958f40d9ae54d85d44c/django/apps/registry.py#L131-L134
 django/apps/registry.py].

--

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

Re: [Django] #30329: Make error message clearer when installed SQLite version is too old.

2019-04-04 Thread Django

* version: 2.2 => master
* type: Uncategorized => Bug
* stage: Unreviewed => Accepted

Comment:

This behavior has been changed somewhere in the Django 2.2. I agree that
it is a bug but probably not crucial. It affects all
`ImproperlyConfigured`'s exceptions, e.g.
- `django.core.exceptions.ImproperlyConfigured: Error loading cx_Oracle
module: No module named 'cx_Oracle'`,
- `django.core.exceptions.ImproperlyConfigured: SQLite 3.8.3 or later is
required (found 3.7.X).`, etc.

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

[Django] #30330: Deletion isn't updating model

2019-04-04 Thread Django

#30330: Deletion isn't updating model
-+-
   Reporter:  Artui  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  2.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  delete, pk
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Deleting any model with no dependencies not updates the PK on the model.
 It should be set to `None` after `.delete()` call.

 See Django.db.models.deletion:276-281. Should update the model line 280.

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

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

Re: [Django] #30329: Make error message clearer when installed SQLite version is too old.

2019-04-04 Thread Django

#30329: Make error message clearer when installed SQLite version is too old.
-+--
 Reporter:  Alasdair Nicol   |Owner:  (none)
 Type:  Uncategorized|   Status:  new
Component:  Error reporting  |  Version:  2.2
 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 Alasdair Nicol:

Old description:

> When an older version of sqlite is installed, the final line of the
> traceback is unrelated.
>
> raise LookupError(message)
> LookupError: No installed app with label 'admin'.
>
> If you look further up the traceback, you can see what the problem is,
> but this can be tricky for newer users.
>
> raise ImproperlyConfigured('SQLite 3.8.3 or later is required (found
> %s).' % Database.sqlite_version)
> django.core.exceptions.ImproperlyConfigured: SQLite 3.8.3 or later is
> required (found 3.7.17).
>
> I think that if we made the error message clearer it would be helpful for
> new users. Perhaps we could do this by checking the sqlite version in a
> system check, or maybe there's a better approach.
>
> Related Stack Overflow question:
> https://stackoverflow.com/questions/55512244/no-installed-app-with-label-
> admin-in-empty-django-2-2-project/

New description:

 When an older version of sqlite is installed, the final line of the
 traceback is unrelated.

 {{{
 raise LookupError(message)
 LookupError: No installed app with label 'admin'.
 }}}

 If you look further up the traceback, you can see what the problem is, but
 this can be tricky for newer users.

 {{{
 raise ImproperlyConfigured('SQLite 3.8.3 or later is required (found
 %s).' % Database.sqlite_version)
 django.core.exceptions.ImproperlyConfigured: SQLite 3.8.3 or later is
 required (found 3.7.17).
 }}}

 I think that if we made the error message clearer it would be helpful for
 new users. Perhaps we could do this by checking the sqlite version in a
 system check, or maybe there's a better approach.

 Related Stack Overflow question:
 https://stackoverflow.com/questions/55512244/no-installed-app-with-label-
 admin-in-empty-django-2-2-project/

--

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

[Django] #30329: Make error message clearer when installed SQLite version is too old.

2019-04-04 Thread Django

#30329: Make error message clearer when installed SQLite version is too old.
---+
Reporter: Alasdair Nicol | Owner: (none)
Type: Uncategorized| Status: new
Component: Error reporting |Version: 2.2
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|
---+
When an older version of sqlite is installed, the final line of the
traceback is unrelated.

raise LookupError(message)
LookupError: No installed app with label 'admin'.

If you look further up the traceback, you can see what the problem is, but
this can be tricky for newer users.

raise ImproperlyConfigured('SQLite 3.8.3 or later is required (found
%s).' % Database.sqlite_version)
django.core.exceptions.ImproperlyConfigured: SQLite 3.8.3 or later is
required (found 3.7.17).

I think that if we made the error message clearer it would be helpful for
new users. Perhaps we could do this by checking the sqlite version in a
system check, or maybe there's a better approach.

Related Stack Overflow question:
https://stackoverflow.com/questions/55512244/no-installed-app-with-label-
admin-in-empty-django-2-2-project/

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

Re: [Django] #30322: DEBUG=False + csrf_exempt(GraphqlView) + gunicorn == crash

2019-04-04 Thread Django

#30322: DEBUG=False + csrf_exempt(GraphqlView) + gunicorn == crash
---+--
 Reporter:  Kurt Neufeld   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Uncategorized  |  Version:  2.1
 Severity:  Normal |   Resolution:  needsinfo
 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 felixxm):

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


Comment:

 Thanks for the report, however we need more information to check if it is
 related with Django itself or not. At first glance it looks like a support
 issue, please use one of
 [https://code.djangoproject.com/wiki/TicketClosingReasons/UseSupportChannels
 support channels].

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

Re: [Django] #30328: Integer field range validators crash when limit_value is callable. (was: Callable passed to Min/Max validators breaks in the fields)

2019-04-04 Thread Django

#30328: Integer field range validators crash when limit_value is callable.
-+-
 Reporter:  Harro|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Release blocker  |   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 felixxm):

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


Comment:

 Reproduced at 1ffddfc233e2d5139cc6ec31a4ec6ef70b10f87f.

 Regression in 24cae0bedc51093b363c323af555946a8edea1a1.

 Thanks for the report!

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

Re: [Django] #30328: Callable passed to Min/Max validators breaks in the fields

2019-04-04 Thread Django

#30328: Callable passed to Min/Max validators breaks in the fields
-+-
 Reporter:  Harro|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Harro):

 Should add that it only fails if the database backend has limits (sqlite
 does not)

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

Re: [Django] #6989: Inability to define DNS_NAME in django.core.mail results in e-mail messages being rejected or marked as spam

2019-04-04 Thread Django

#6989: Inability to define DNS_NAME in django.core.mail results in e-mail 
messages
being rejected or marked as spam
-+-
 Reporter:  Franklin |Owner:  heathervm
 Type:  Bug  |   Status:  assigned
Component:  Core (Mail)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  local_hostname,  | Triage Stage:  Accepted
  DNS_NAME, CachedDnsName, smtplib,  |
  SMTPConnection |
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Diederik van der Boor):

 I bumbed into this again, in the end I had to fix this by patching:

 `django.core.mail.utils.DNS_NAME._fqdn = "my.desired.host"`

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

Re: [Django] #30328: Callable passed to Min/Max validators breaks in the fields

2019-04-04 Thread Django

#30328: Callable passed to Min/Max validators breaks in the fields
-+-
 Reporter:  Harro|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Description changed by Harro:

Old description:

> in #29860 for django 2.2 the option was added to pass in a callable.
>
> I just upgraded to django 2.2 and found our custom max value validator
> for current year + 1 (which gave us a migration on the year change) and
> thought to replace it with the new mechanic.
>
> The result was the following error:
> `
>   File "/lib/python3.6/site-
> packages/django/db/models/fields/__init__.py", line 1799, in 
> validator.limit_value <= max_value for validator in validators_)):
> `
>
> So the field wants to check that the validator's max (and min) value lie
> within range of the Integer field which is not possible with the
> callable.
>
> The fix should be simple: Check if it's a callable and call it for the
> value.

New description:

 in #29860 for django 2.2 the option was added to pass in a callable.

 I just upgraded to django 2.2 and found our custom max value validator for
 current year + 1 (which gave us a migration on the year change) and
 thought to replace it with the new mechanic.

 The result was the following error:
 {{{
   File "/lib/python3.6/site-
 packages/django/db/models/fields/__init__.py", line 1799, in 
 validator.limit_value <= max_value for validator in validators_)):
 }}}

 So the field wants to check that the validator's max (and min) value lie
 within range of the Integer field which is not possible with the callable.

 The fix should be simple: Check if it's a callable and call it for the
 value.

--

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

Re: [Django] #30328: Callable passed to Min/Max validators breaks in the fields

2019-04-04 Thread Django

#30328: Callable passed to Min/Max validators breaks in the fields
-+-
 Reporter:  Harro|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Description changed by Harro:

Old description:

> in #29860 for django 2.2 the option was added to pass in a callable.
>
> I just upgraded to django 2.2 and found our custom max value validator
> for current year + 1 (which gave us a migration on the year change) and
> thought to replace it with the new mechanic.
>
> The result was the following error:
> ```
>   File "/lib/python3.6/site-
> packages/django/db/models/fields/__init__.py", line 1799, in 
> validator.limit_value <= max_value for validator in validators_)):
> ```
>
> So the field wants to check that the validator's max (and min) value lie
> within range of the Integer field which is not possible with the
> callable.
>
> The fix should be simple: Check if it's a callable and call it for the
> value.

New description:

 in #29860 for django 2.2 the option was added to pass in a callable.

 I just upgraded to django 2.2 and found our custom max value validator for
 current year + 1 (which gave us a migration on the year change) and
 thought to replace it with the new mechanic.

 The result was the following error:
 `
   File "/lib/python3.6/site-
 packages/django/db/models/fields/__init__.py", line 1799, in 
 validator.limit_value <= max_value for validator in validators_)):
 `

 So the field wants to check that the validator's max (and min) value lie
 within range of the Integer field which is not possible with the callable.

 The fix should be simple: Check if it's a callable and call it for the
 value.

--

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

[Django] #30328: Callable passed to Min/Max validators breaks in the fields

2019-04-04 Thread Django

I just upgraded to django 2.2 and found our custom max value validator for
current year + 1 (which gave us a migration on the year change) and
thought to replace it with the new mechanic.

The result was the following error:
```
File "/lib/python3.6/site-
packages/django/db/models/fields/__init__.py", line 1799, in
validator.limit_value <= max_value for validator in validators_)):
```

So the field wants to check that the validator's max (and min) value lie
within range of the Integer field which is not possible with the callable.

The fix should be simple: Check if it's a callable and call it for the
value.

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

Re: [Django] #30325: Inconsistent count() behaviour on reverse relations in ManyToManyFields with custom model manager

2019-04-04 Thread Django

#30325: Inconsistent count() behaviour on reverse relations in ManyToManyFields
with custom model manager
-+-
 Reporter:  Tobias Kunze |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Marten Kenbeek):

 Regression caused by [changeset:"1299421cadc4fcf63585f2f88337078e43e660e0"
 1299421] (#29725). `.count()` and `.exists()` on a many-to-many relation
 now use the through model's base manager instead of the related model's
 default manager.

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

Re: [Django] #30327: Failing collectstatic with ManifestFilesMixin

2019-04-04 Thread Django

#30327: Failing collectstatic with ManifestFilesMixin
-+-
 Reporter:  Gadir Rustamli   |Owner:  Gadir
 |  Rustamli
 Type:  Bug  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  2.2
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  staticfiles  | Triage Stage:
  versioning |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * status:  assigned => closed
 * resolution:   => invalid
 * severity:  Release blocker => Normal


Comment:

 This is not a bug in Django itself. `S3Boto3Storage` or
 `ManifestFilesMixin` are not provided by Django. It looks like a typo in
 `s3transfer` package, i.e. `ContentLength` instead of `Content-Length`.

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

Re: [Django] #30307: dbshell doesn't pass password properly on Oracle 18c.

2019-04-04 Thread Django

#30307: dbshell doesn't pass password properly on Oracle 18c.
-+-
 Reporter:  Mark Gordon  |Owner:  msg555@…
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  oracle dbshell   | Triage Stage:  Ready for
  runshell   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"1279fb4a00c23ab0b9aeff8dd205661d4e9a8110" 1279fb4a]:
 {{{
 #!CommitTicketReference repository=""
 revision="1279fb4a00c23ab0b9aeff8dd205661d4e9a8110"
 [2.2.x] Fixed #30307 -- Fixed incorrect quoting of database user password
 when using dbshell on Oracle.

 Regression in acfc650f2a6e4a79e80237eabfa923ea3a05d709.

 Backport of 755673e1bca7edb6bee7a958f40d9ae54d85d44c 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/064.a9b2969301f9d64ef370578af700b158%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30307: dbshell doesn't pass password properly on Oracle 18c.

2019-04-04 Thread Django

#30307: dbshell doesn't pass password properly on Oracle 18c.
-+-
 Reporter:  Mark Gordon  |Owner:  msg555@…
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  oracle dbshell   | Triage Stage:  Ready for
  runshell   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"755673e1bca7edb6bee7a958f40d9ae54d85d44c" 755673e]:
 {{{
 #!CommitTicketReference repository=""
 revision="755673e1bca7edb6bee7a958f40d9ae54d85d44c"
 Fixed #30307 -- Fixed incorrect quoting of database user password when
 using dbshell on Oracle.

 Regression in acfc650f2a6e4a79e80237eabfa923ea3a05d709.
 }}}

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

Re: [Django] #30325: Inconsistent count() behaviour on reverse relations in ManyToManyFields with custom model manager

2019-04-04 Thread Django

#30325: Inconsistent count() behaviour on reverse relations in ManyToManyFields
with custom model manager
-+-
 Reporter:  Tobias Kunze |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tobias Kunze):

 > This is not a bug!

 Could you elaborate on this? As it is changed behaviour from Django 2.1
 and previous versions, it's either a bug/regression, or a documentation
 bug by not mentioning this changed behaviour in the release notes, in my
 opinion. Up until now I've assumed that `something.related.count()` and
 `something.related.all().count()` will yield the same result, and if this
 is not true, it should be documented. (Or is it documented? Could you
 point me at the right place to look?)

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

Re: [Django] #30325: Inconsistent count() behaviour on reverse relations in ManyToManyFields with custom model manager

2019-04-04 Thread Django

#30325: Inconsistent count() behaviour on reverse relations in ManyToManyFields
with custom model manager
-+-
 Reporter:  Tobias Kunze |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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


Comment:

 PizzolatoDavide Please do not shout.

 `a.books.count() != a.books.all().count()` for me it is a bug, moreover
 this behavior has changed in Django 2.2.

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

Re: [Django] #30325: Inconsistent count() behaviour on reverse relations in ManyToManyFields with custom model manager

2019-04-04 Thread Django

#30325: Inconsistent count() behaviour on reverse relations in ManyToManyFields
with custom model manager
-+-
 Reporter:  Tobias Kunze |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  invalid
 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 PizzolatoDavide):

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


Comment:

 This is not a bug!

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

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

Re: [Django] #30327: Failing collectstatic with ManifestFilesMixin

2019-04-04 Thread Django

#30327: Failing collectstatic with ManifestFilesMixin
-+-
 Reporter:  Grustamli|Owner:  Grustamli
 Type:  Bug  |   Status:  assigned
Component:  contrib.staticfiles  |  Version:  2.2
 Severity:  Release blocker  |   Resolution:
 Keywords:  staticfiles  | Triage Stage:
  versioning |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Grustamli):

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


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

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

[Django] #30327: Failing collectstatic with ManifestFilesMixin

2019-04-04 Thread Django

#30327: Failing collectstatic with ManifestFilesMixin
-+-
   Reporter:  Grustamli  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component: |Version:  2.2
  contrib.staticfiles|
   Severity:  Release|   Keywords:  staticfiles
  blocker|  versioning
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Collectstatic throws `KeyError: 'ContentLength'` when used with
 ManifestFileMixin. Below is the custom storage class I've written to
 upload the files to Google Cloud Storage.

 {{{
 class CustomStorage(ManifestFilesMixin, S3Boto3Storage):
  pass
 }}}

 in the settings.py

 {{{
 STATICFILES_STORAGE = 'myapp.storage.CustomStorage'
 }}}


 And here is the stacktrace:

 {{{
 UserWarning: The default behavior of S3Boto3Storage is insecure and will
 change in django-storages 2.0. By default files and new buckets are saved
 with an ACL of 'public-read' (globally publicly readable). Version 2.0
 will default to using the bucket's ACL. To opt into the new behavior set
 AWS_DEFAULT_ACL = None, otherwise to silence this warning explicitly set
 AWS_DEFAULT_ACL.
   "The default behavior of S3Boto3Storage is insecure and will change "
 Traceback (most recent call last):
   File "./manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "/home/ufaz/webapps/ufaz_website/.venv/lib/python3.6/site-
 packages/django/core/management/__init__.py", line 381, in
 execute_from_command_line
 utility.execute()
   File "/home/ufaz/webapps/ufaz_website/.venv/lib/python3.6/site-
 packages/django/core/management/__init__.py", line 375, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/home/ufaz/webapps/ufaz_website/.venv/lib/python3.6/site-
 packages/django/core/management/base.py", line 316, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/home/ufaz/webapps/ufaz_website/.venv/lib/python3.6/site-
 packages/django/core/management/base.py", line 353, in execute
 output = self.handle(*args, **options)
   File "/home/ufaz/webapps/ufaz_website/.venv/lib/python3.6/site-
 packages/django/contrib/staticfiles/management/commands/collectstatic.py",
 line 188, in handle
 collected = self.collect()
   File "/home/ufaz/webapps/ufaz_website/.venv/lib/python3.6/site-
 packages/django/contrib/staticfiles/management/commands/collectstatic.py",
 line 128, in collect
 for original_path, processed_path, processed in processor:
   File "/home/ufaz/webapps/ufaz_website/.venv/lib/python3.6/site-
 packages/django/contrib/staticfiles/storage.py", line 402, in post_process
 yield from super().post_process(*args, **kwargs)
   File "/home/ufaz/webapps/ufaz_website/.venv/lib/python3.6/site-
 packages/django/contrib/staticfiles/storage.py", line 236, in post_process
 for name, hashed_name, processed, _ in self._post_process(paths,
 adjustable_paths, hashed_files):
   File "/home/ufaz/webapps/ufaz_website/.venv/lib/python3.6/site-
 packages/django/contrib/staticfiles/storage.py", line 293, in
 _post_process
 content = pattern.sub(converter, content)
   File "/home/ufaz/webapps/ufaz_website/.venv/lib/python3.6/site-
 packages/django/contrib/staticfiles/storage.py", line 194, in converter
 force=True, hashed_files=hashed_files,
   File "/home/ufaz/webapps/ufaz_website/.venv/lib/python3.6/site-
 packages/django/contrib/staticfiles/storage.py", line 131, in _url
 hashed_name = hashed_name_func(*args)
   File "/home/ufaz/webapps/ufaz_website/.venv/lib/python3.6/site-
 packages/django/contrib/staticfiles/storage.py", line 342, in _stored_name
 cache_name = self.clean_name(self.hashed_name(name))
   File "/home/ufaz/webapps/ufaz_website/.venv/lib/python3.6/site-
 packages/django/contrib/staticfiles/storage.py", line 99, in hashed_name
 file_hash = self.file_hash(clean_name, content)
   File "/home/ufaz/webapps/ufaz_website/.venv/lib/python3.6/site-
 packages/django/contrib/staticfiles/storage.py", line 79, in file_hash
 for chunk in content.chunks():
   File "/home/ufaz/webapps/ufaz_website/.venv/lib/python3.6/site-
 packages/django/core/files/base.py", line 55, in chunks
 self.seek(0)
   File "/home/ufaz/webapps/ufaz_website/.venv/lib/python3.6/site-
 packages/django/core/files/utils.py", line 20, in 
 seek = property(lambda self: self.file.seek)
   File "/home/ufaz/webapps/ufaz_website/.venv/lib/python3.6/site-
 packages/storages/backends/s3boto3.py", line 97, in _get_file
 self.obj.download_fileobj(self._file)
   File

Re: [Django] #30325: Inconsistent count() behaviour on reverse relations in ManyToManyFields with custom model manager

2019-04-04 Thread Django

#30325: Inconsistent count() behaviour on reverse relations in ManyToManyFields
with custom model manager
-+-
 Reporter:  Tobias Kunze |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * status:  closed => new
 * resolution:  invalid =>
 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


Comment:

 Reproduced at 1ffddfc233e2d5139cc6ec31a4ec6ef70b10f87f and works in Django
 2.1.

 Thanks for the report. Can you bisect to check which commit change this
 behavior?

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

Re: [Django] #30325: Inconsistent count() behaviour on reverse relations in ManyToManyFields with custom model manager

2019-04-04 Thread Django

#30325: Inconsistent count() behaviour on reverse relations in ManyToManyFields
with custom model manager
-+-
 Reporter:  Tobias Kunze |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 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 PizzolatoDavide):

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


Comment:

 a.books.all() is managed by the BookManager so it exclude the 'deleted'
 book b1

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

Re: [Django] #30324: UnicodeDecodeError when loading debug templates.

2019-04-04 Thread Django

#30324: UnicodeDecodeError when loading debug templates.
-+-
 Reporter:  chihun-jang  |Owner:  Nick Pope
 Type:  Bug  |   Status:  assigned
Component:  Error reporting  |  Version:  2.2
 Severity:  Release blocker  |   Resolution:
 Keywords:  runserver,   | Triage Stage:  Accepted
  UnicodeDecodeError,|
  cp949,template,technical_500   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felixxm):

 Original ticket that describes the same issue #30303.

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

Re: [Django] #30303: Error handler page generating unicode decode error.

2019-04-04 Thread Django

#30303: Error handler page generating unicode decode error.
-+--
 Reporter:  Kevin Golding|Owner:  (none)
 Type:  Bug  |   Status:  closed
Component:  Error reporting  |  Version:  2.2
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  wsgi unicode | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by felixxm):

 * resolution:  needsinfo => duplicate


Comment:

 Duplicate of #30324.

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

Re: [Django] #30307: dbshell doesn't pass password properly on Oracle 18c.

2019-04-04 Thread Django

#30307: dbshell doesn't pass password properly on Oracle 18c.
-+-
 Reporter:  Mark Gordon  |Owner:  msg555@…
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle dbshell   | Triage Stage:  Ready for
  runshell   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * needs_better_patch:  1 => 0
 * 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/064.fa39f7e279864f798ae47df60080bfd8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30324: UnicodeDecodeError when loading debug templates.

2019-04-04 Thread Django

#30324: UnicodeDecodeError when loading debug templates.
-+-
 Reporter:  chihun-jang  |Owner:  Nick Pope
 Type:  Bug  |   Status:  assigned
Component:  Error reporting  |  Version:  2.2
 Severity:  Release blocker  |   Resolution:
 Keywords:  runserver,   | Triage Stage:  Accepted
  UnicodeDecodeError,|
  cp949,template,technical_500   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * severity:  Normal => Release blocker


Comment:

 Upgrading to Release Blocker. Thanks for the report!

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

44 matches

Mail list logo