Re: [Django] #28222: Django 1.11 update_or_create field validation results in different behaviours between create and update_or_create

[Django]

#28222: Django 1.11 update_or_create field validation results in different
behaviours between create and update_or_create
-+-
 Reporter:  Alex Mykyta  |Owner:  Alex
 |  Mykyta
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  1.11 | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Alex Mykyta):

 * owner:  nobody => Alex Mykyta
 * 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/065.d2481fe397798293c1ad9c7d8d12581e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28222: Django 1.11 update_or_create field validation results in different behaviours between create and update_or_create

[Django]

#28222: Django 1.11 update_or_create field validation results in different
behaviours between create and update_or_create
-+-
 Reporter:  Alex Mykyta  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  1.11 | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Alex Mykyta):

 * component:  Uncategorized => Database layer (models, ORM)


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

Re: [Django] #28222: Django 1.11 update_or_create field validation results in different behaviours between create and update_or_create

[Django]

#28222: Django 1.11 update_or_create field validation results in different
behaviours between create and update_or_create
---+--
 Reporter:  Alex Mykyta|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.11
 Severity:  Normal |   Resolution:
 Keywords:  1.11   | 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 Alex Mykyta:

Old description:

> This is an issue related to #27118. Anthony King commented on it but that
> issue is closed so I am opening a new one. The field validation
> introduced in 1.11 `update_or_create` will throw a FieldError if a
> `defaults` argument contains a value that is set through an
> `@property.setter` on that model. On the other hand `create` continues to
> function correctly. Ideally they'd behave consistently.
>
> Here is an example https://dpaste.de/UORC

New description:

 This is an issue related to #27118. Anthony King commented on it but that
 issue is closed so I am opening a new one. The field validation introduced
 in 1.11 `update_or_create` will throw a `FieldError` if a `defaults`
 argument contains a value that is set through an `@property.setter` on
 that model. On the other hand `create` continues to function correctly.
 Ideally they'd behave consistently.

 Here is an example https://dpaste.de/UORC

--

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

[Django] #28222: Django 1.11 update_or_create field validation results in different behaviours between create and update_or_create

[Django]

#28222: Django 1.11 update_or_create field validation results in different
behaviours between create and update_or_create
-+
   Reporter:  Alex Mykyta|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Uncategorized  |Version:  1.11
   Severity:  Normal |   Keywords:  1.11
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 This is an issue related to #27118. Anthony King commented on it but that
 issue is closed so I am opening a new one. The field validation introduced
 in 1.11 `update_or_create` will throw a FieldError if a `defaults`
 argument contains a value that is set through an `@property.setter` on
 that model. On the other hand `create` continues to function correctly.
 Ideally they'd behave consistently.

 Here is an example https://dpaste.de/UORC

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

Re: [Django] #28168: Using qs.order_by() and qs.values() with JSONFields

[Django]

#28168: Using qs.order_by() and qs.values() with JSONFields
-+-
 Reporter:  Austin Roberts   |Owner:  (none)
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.postgres |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Matthew Wilkes):

 I think this might be a subset of #24747 ?

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

Re: [Django] #28211: Inefficient query produced when using OR'ed Q objects

[Django]

#28211: Inefficient query produced when using OR'ed Q objects
-+-
 Reporter:  Tom  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.10
  (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 Tom):

 * has_patch:  0 => 1


Comment:

 I added a patch here: https://github.com/django/django/pull/8517

 I took the easy route and fixed what I think is an issue in the `Q`
 object. Combining empty `Q` objects should be a no-op. This effectively
 fixes this ticket without many changes.

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

Re: [Django] #28220: contrib.auth.models Group should have a default ordering to prevent UnorderedObjectListWarning

[Django]

#28220: contrib.auth.models Group should have a default ordering to prevent
UnorderedObjectListWarning
-+-
 Reporter:  Denise Mauldin   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  1.11
 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 Denise Mauldin):

 Will do.  Just was hoping there was a faster way than updating all of our
 code.  Thanks.

 Replying to [comment:1 Simon Charette]:
 > Defining a default ordering coud break existing application and would
 most likely require a migration for the `_meta.ordering` change.
 >
 > The only paginated use of `Group`'s manager is through `GroupAdmin`
 which is
 
[https://github.com/django/django/blob/650bf6714d5648811a8bc08ce53b7fa86cc38d40/django/contrib/auth/admin.py#L29
 already ordered] by `name`.
 >
 > Is there a reason you can't explicitly specify an ordering when exposing
 groups through a paginated view by using `order_by()`?

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

Re: [Django] #28206: Raw queries with Oracle impossible when using uppercase column names

[Django]

#28206: Raw queries with Oracle impossible when using uppercase column names
-+-
 Reporter:  Dmitry Shachnev  |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  Oracle   | 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 GitHub ):

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


Comment:

 In [changeset:"99df304c856ac2f6ee18418ea8ca3e2dc7b47dac" 99df304]:
 {{{
 #!CommitTicketReference repository=""
 revision="99df304c856ac2f6ee18418ea8ca3e2dc7b47dac"
 Fixed #28206 -- Fixed RawQuerySet crash on a model with a mixed case
 db_column pk on Oracle.

 Thanks Tim Graham for the 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/065.4a5103f14460f701ce805157bbba6eca%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28102: Document how to put the full path of the built-in widget directories in DIRS

[Django]

#28102: Document how to put the full path of the built-in widget directories in
DIRS
-+-
 Reporter:  Richard Eames|Owner:  Windson
 Type:   |  yang
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham):

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

Re: [Django] #28017: Add option to specify a different secret to PasswordResetTokenGenerator

[Django]

#28017: Add option to specify a different secret to PasswordResetTokenGenerator
--+--
 Reporter:  Jann Haber|Owner:  Jann Haber
 Type:  New feature   |   Status:  assigned
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+--
Changes (by Tim Graham):

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

Re: [Django] #28210: `._state.adding` behaviour and model inheritance

[Django]

#28210: `._state.adding` behaviour and model inheritance
-+-
 Reporter:  Ivaylo Donchev   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (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 Simon Charette):

 * cc: Simon Charette (added)
 * severity:  Normal => Release blocker


Comment:

 Tentatively escalating as a release blocker as everything seems to
 indicate this is a regression.

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

Re: [Django] #28203: assertNumQueries should ignore initial connection configuration queries

[Django]

#28203: assertNumQueries should ignore initial connection configuration queries
-+-
 Reporter:  François Freitag |Owner:  François
 |  Freitag
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  assertNumQueries | 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:"98b3b14a648a128d409b8f6169c1a4ff9d71c1a4" 98b3b14a]:
 {{{
 #!CommitTicketReference repository=""
 revision="98b3b14a648a128d409b8f6169c1a4ff9d71c1a4"
 Fixed #28203 -- Ignored connection configuration queries in
 assertNumQueries().
 }}}

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

Re: [Django] #27899: Phrase search query for Postgres full text search

[Django]

#27899: Phrase search query for Postgres full text search
-+-
 Reporter:  Ilya Semenov |Owner:  Andrii
 |  Soldatenko
 Type:  New feature  |   Status:  assigned
Component:  contrib.postgres |  Version:  master
 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 Andrii Soldatenko):

 * needs_docs:  1 => 0


Comment:

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

Re: [Django] #28168: Using qs.order_by() and qs.values() with JSONFields

[Django]

#28168: Using qs.order_by() and qs.values() with JSONFields
-+-
 Reporter:  Austin Roberts   |Owner:  (none)
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.postgres |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * cc: Marc Tamlyn (added)


Old description:

> When using JSONFields, I expected to be able to construct a queryset
> like:
>
> MyModel.objects.all().order_by("metadata__some__field")
>
> where "metadata" is a JSONField, "some" is a key in that JSONField, and
> "field" is a key within the "some" dictionary.
>
> When I try, however, Django treats it as a join instead of a metadata
> field lookup, and I get this:
>

> {{{
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/home/aroberts/.virtualenvs/example/local/lib/python2.7/site-
> packages/django/db/models/query.py", line 226, in __repr__
> data = list(self[:REPR_OUTPUT_SIZE + 1])
>   File "/home/aroberts/.virtualenvs/example/local/lib/python2.7/site-
> packages/django/db/models/query.py", line 250, in __iter__
> self._fetch_all()
>   File "/home/aroberts/.virtualenvs/example/local/lib/python2.7/site-
> packages/django/db/models/query.py", line 1102, in _fetch_all
> self._result_cache = list(self._iterable_class(self))
>   File "/home/aroberts/.virtualenvs/example/local/lib/python2.7/site-
> packages/django/db/models/query.py", line 53, in __iter__
> results = compiler.execute_sql(chunked_fetch=self.chunked_fetch)
>   File "/home/aroberts/.virtualenvs/example/local/lib/python2.7/site-
> packages/django/db/models/sql/compiler.py", line 863, in execute_sql
> sql, params = self.as_sql()
>   File "/home/aroberts/.virtualenvs/example/local/lib/python2.7/site-
> packages/django/db/models/sql/compiler.py", line 412, in as_sql
> extra_select, order_by, group_by = self.pre_sql_setup()
>   File "/home/aroberts/.virtualenvs/example/local/lib/python2.7/site-
> packages/django/db/models/sql/compiler.py", line 47, in pre_sql_setup
> order_by = self.get_order_by()
>   File "/home/aroberts/.virtualenvs/example/local/lib/python2.7/site-
> packages/django/db/models/sql/compiler.py", line 298, in get_order_by
> field, self.query.get_meta(), default_order=asc))
>   File "/home/aroberts/.virtualenvs/example/local/lib/python2.7/site-
> packages/django/db/models/sql/compiler.py", line 593, in
> find_ordering_name
> field, targets, alias, joins, path, opts = self._setup_joins(pieces,
> opts, alias)
>   File "/home/aroberts/.virtualenvs/example/local/lib/python2.7/site-
> packages/django/db/models/sql/compiler.py", line 626, in _setup_joins
> pieces, opts, alias)
>   File "/home/aroberts/.virtualenvs/example/local/lib/python2.7/site-
> packages/django/db/models/sql/query.py", line 1427, in setup_joins
> names, opts, allow_many, fail_on_missing=True)
>   File "/home/aroberts/.virtualenvs/example/local/lib/python2.7/site-
> packages/django/db/models/sql/query.py", line 1395, in names_to_path
> " not permitted." % (names[pos + 1], name))
> FieldError: Cannot resolve keyword 'some' into field. Join on 'metadata'
> not permitted.
> }}}
>
> For now, I'm able to work around this by instead doing:
>
> {{{
> from django.db.models.expressions import OrderBy, RawSQL
>
> MyModel.objects.all().order_by(OrderBy(RawSQL("metadata #> '{some}' #>
> '{field}'", []))
> }}}
>
> Similarly, I have cases where I want to be able to do
>
> {{{
> MyModel.objects.all().values("metadata__some__field")
> }}}
>
> I've worked out a similar work around of
>
> {{{
> MyModel.objects.all().annotate(some_field=RawSQL("metadata #> '{some}' #>
> '{field}'", [])).values("some_field")
> }}}
>
> Both of these are things it would be nice to have cleaner, more natural
> syntax for in Django. I'm not sure how deep the changes would have to be,
> whether it could just be addressed in the contrib or if it would require
> core changes. In any case, I suspect there will be other people looking
> for workarounds like this, so I figured I'd share my findings.

New description:

 When using JSONFields, I expected to be able to construct a queryset like:

 `MyModel.objects.all().order_by("metadata__some__field")`

 where "metadata" is a JSONField, "some" is a key in that JSONField, and
 "field" is a key within the "some" dictionary.

 When I try, however, Django treats it as a join instead of a 

Re: [Django] #28118: reverse() and get_absolute_url() may return different output for same FlatPage (was: reverse() and get_absolute_url() returns different output for same object ?)

[Django]

#28118: reverse() and get_absolute_url() may return different output for same
FlatPage
---+
 Reporter:  Pat|Owner:  Michal
 Type:  Bug|   Status:  new
Component:  contrib.flatpages  |  Version:  1.8
 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 Tim Graham):

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

Re: [Django] #28217: nested calls to functions decorated with sensitive_post_parameters produces unexpected results which parameters are considered sensitive

[Django]

#28217: nested calls to functions decorated with sensitive_post_parameters 
produces
unexpected results which parameters are considered sensitive
-+--
 Reporter:  Peter Zsoldos|Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Error reporting  |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by Tim Graham):

 I'm not sure if it's worth trying to support this use case. The
 `@sensitive_post_parameters` decorator is documented to be used on a view.
 Do you have a use case for nested views like 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/066.066f3c5593ed772685afe8034a103e96%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28220: contrib.auth.models Group should have a default ordering to prevent UnorderedObjectListWarning

[Django]

#28220: contrib.auth.models Group should have a default ordering to prevent
UnorderedObjectListWarning
-+-
 Reporter:  Denise Mauldin   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  1.11
 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 Tim Graham):

 * status:  new => closed
 * component:  Uncategorized => contrib.auth
 * resolution:   => wontfix
 * type:  Uncategorized => Cleanup/optimization


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

Re: [Django] #28206: Raw queries with Oracle impossible when using uppercase column names

[Django]

#28206: Raw queries with Oracle impossible when using uppercase column names
-+-
 Reporter:  Dmitry Shachnev  |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Oracle   | 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 Tim Graham):

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

Re: [Django] #28210: `._state.adding` behaviour and model inheritance

[Django]

#28210: `._state.adding` behaviour and model inheritance
-+-
 Reporter:  Ivaylo Donchev   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (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
-+-

Comment (by Ivaylo Donchev):

 Well, I hit this bug while upgrading Django from 1.10 to 1.11.1, but I
 didn't reproduce all the corner cases in the Django1.10.
 Replying to [comment:3 Simon Charette]:
 > Could you confirm whether or not it's a regression from 1.10? It could
 be related to 38575b007a722d6af510ea46d46393a4cda9ca29 as well.

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

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

Re: [Django] #28152: Change SetSerializer to serialize to set literals

[Django]

#28152: Change SetSerializer to serialize to set literals
-+-
 Reporter:  Jon Dufresne |Owner:  Jon
 Type:   |  Dufresne
  Cleanup/optimization   |   Status:  closed
Component:  Migrations   |  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:"f599747fc802f1db6cd4394c33fc9afb8aac370b" f599747]:
 {{{
 #!CommitTicketReference repository=""
 revision="f599747fc802f1db6cd4394c33fc9afb8aac370b"
 Fixed #28152 -- Made migrations serialize sets as set literals rather than
 set().
 }}}

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

Re: [Django] #28221: Fallback language overrides plural forms

[Django]

#28221: Fallback language overrides plural forms
--+
 Reporter:  Waldemar Kornewald|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  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 Claude Paroz):

 * version:  1.11 => master
 * 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/068.75e79421f511d3b21437225cc5d0f7ef%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28215: sensitive_post_parameters/sensitive_variables leaking sensitive values into the http 500 exception email

[Django]

#28215: sensitive_post_parameters/sensitive_variables leaking sensitive values 
into
the http 500 exception email
-+--
 Reporter:  Peter Zsoldos|Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Error reporting  |  Version:  1.8
 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 Peter Zsoldos):

 Tim,

 thanks for the feedback. For the time being, I copypasted the repro
 unittest's main body into the ticket so it's more accessible.

 As for the suggested fix, I think there are two separate issues here

 1. sensitive data across django's own internal code is not marked
 everywhere as sensitive. This can be fixed manually once and that would be
 a great improvement.
 * There is one scenario highlighted in this ticket (error during
 login),
 * Probably all `sensitive_post_parameter` decorated views need to be
 reviewed & followed through the code paths to ensure all sensitive
 variables in all methods are decorated
 * For future code changes, checking for the need to update the
 sensitive parameters would need to be done too.
 * this only fixes things in Django's own code though, not issues in
 third party code, though it could be argued that they should write secure
 code & users of 3rd party code should do due diligence...
 1. however, some generic code might be used from multiple contexts, even
 from multiple `sensitive_post_parameter` views - e.g.:
 `MyModel.objects.get`. In some contexts, `username` field might be
 sensitive (e.g.: login), but in others (e.g.: admin search) it might not.
 See the below simplified unittest to repro it - it is displayed for the
 frame `django/db/models/query.py` in `get`.

 {{{#!python

 @sensitive_variables('username')  # to exclude the local var in the
 stacktrace here
 def test_leaking_data_due_to_exception_in_generic_method(self):

 class TestError(ValueError):
 pass


 @sensitive_post_parameters('username')
 def some_view(request):
 """
 based on docstring from sensitive_post_parameters itself,
 storing it into a local variable.
 But same issue would happen if I the User.objects.get raised
 the User.DoesNotExist error - and how should the generic
 QuerySet.get be annotated with regards to all sensitive
 parameters?
 """
 uname = request.POST['username']
 User.objects.get(username=request.POST['username'])
 raise TestError('some error')

 username = 'some_username'
 rf = RequestFactory()
 request = rf.post('/submit/', {'username': username})
 try:
 some_view(request)
 raise ValueError('expected to raise an error')
 except (TestError, User.DoesNotExist) as e:
 exc_type, exc_value, tb = sys.exc_info()
 # based on django.utils.log.AdminEmailHandler.emit
 reporter = ExceptionReporter(
 request=request, is_email=True,
 exc_type=exc_type, exc_value=exc_value, tb=tb)
 self.assertTrue(reporter.filter.is_active(request))
 error_mail_html = reporter.get_traceback_html()
 self.assertNotIn(
 member=username, container=error_mail_html)
 }}}

 Maybe the ticket should be split in two? 'coz doing 1. would already
 improve the situation quite a bit, but to support 2. might be a bigger
 effort. But I like the test repro for 2 better than the original report's
 - not replacing the ticket description with it until I know whether the
 ticket will be split

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

[Django] #28221: Fallback language overrides plural forms

[Django]

#28221: Fallback language overrides plural forms
+
   Reporter:  Waldemar Kornewald|  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  Internationalization  |Version:  1.11
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 When a plural translation is added to an English djangojs.po file all
 other languages' translations for that plural form are overridden with the
 English (i.e. fallback) translation.

 Pull request with fix is here:
 https://github.com/django/django/pull/8510

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

Re: [Django] #28215: sensitive_post_parameters/sensitive_variables leaking sensitive values into the http 500 exception email

[Django]

#28215: sensitive_post_parameters/sensitive_variables leaking sensitive values 
into
the http 500 exception email
-+--
 Reporter:  Peter Zsoldos|Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Error reporting  |  Version:  1.8
 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 Peter Zsoldos:

Old description:

> == tl;dr
>
> despite using sensitive_xxx decorator, sensitive data can end up in the
> 500 error emails Django sends, as these decorators only protect the data
> inside the very function they are decorated
>
> == repro
>
> Is attached for all current supported Django versions (1.8, 1.10, 1.11),
> simply unpack and run `tox`
>
> The test can seem complicated due to the limitations of the test client
> in testing 500 responses - see #18707
>
> == why I think it is an issue
>
> While I'm aware of the [disclaimers in the documentation about filtering
> sensitive data (https://docs.djangoproject.com/en/1.8/howto/error-
> reporting/#custom-error-reports), because of the impact of it - even on
> users who don't explicitly use any of the `sensitive_x` decorators
> themselves, I think it is a leak that should be stopped.
>
> * typical sensitive data is passwords. We have discovered this issue due
> to a bug in our custom authentication backend. These passwords could also
> be used beyond just the single Django system - whether because of single
> sign on solutions like LDAP/active-directory, or simply because users
> might reuse their passwords across sites
> * exception emails might be sent through third party providers, which may
> keep track of the sent message body. Internal IT departments might also
> be considered such 3rd parties too.
> * support people (admins receiving 500 emails) see supposedly private
> data
>
> == potential solution ideas (which might be wrong of course :))
>
> === writing a custom exception filter
>

>* simply don't report any variables once encountered -
> https://gist.github.com/zsoldosp/5710abaa9dedc03417d60bcc714c95d4
>* keep track of protected variable names and replace those in frames
> further down the stack (i.e.: if parameter 'password', is sensitive,
> cleanse variables names 'password' too in all methods)
>
> === wrapping sensitive variables into a special object
>
> Instead of just using the sensitive data in reporting, wrap these
> variables in an object that has 'contains_sensitive_data' attribute,
> i.e.: if it is stored into another variable, as it is a 'pointer' to the
> original, it will have that attribute, and thus can be filtered out in
> the exception report.
>
> This isn't perfect either, e.g.: `password = password.strip()`, though by
> overriding a lot of methods or using `__getattr__` magic, it could work.
> Might only be 'reasonable' to do so for request parameters, as there at
> least we know the limited set of variable types we receive
>
> {{{#!python
>   @sensitive_request_params
>   def view(request):
>   
>
>   # inside sensitive_request_params
>   for sensitive_variable_name in sensitive_variable_names:
>   if sensitive_variable_name in request.POST:
>  request.POST[sensitive_variable_name] =
> SensitiveVariable(request.POST[sensitive_variable_name])
>   
>   }}}

New description:

 == tl;dr

 despite using sensitive_xxx decorator, sensitive data can end up in the
 500 error emails Django sends, as these decorators only protect the data
 inside the very function they are decorated

 == repro

 {{{#!python
 class ReproTestCase(TransactionTestCase):

 def
 
test_when_login_view_raises_an_exception_password_is_not_in_the_500_email(self):
 # noqa: E501
 password = '$0m3 P4$$w0rd'
 exception_email_html_body =
 self.get_500_email_html_for_login_error(
 username='some_user', password=password
 )
 self.assertNotIn(
 member=password, container=exception_email_html_body)

 def get_500_email_html_for_login_error(self, username, password):
 # patch this methodd so AuthenticationForm.clean is
 # called which has local password variable
 login_view_raising_value_error = patch(
 'django.contrib.auth.forms.authenticate',
 side_effect=ValueError('some error')
 )

 self.goto_login_page()

 with TestClientNotRaisingExceptionButCapturing(self.client) as
 capture:  # see implementation details in attachment
 with login_view_raising_value_error: