Re: [Django] #29206: ValidationError when a reset password link contains a bad UIDB64 UUID

[Django]

#29206: ValidationError when a reset password link contains a bad UIDB64 UUID
-+-
 Reporter:  Mattia Procopio  |Owner:  Mattia
 |  Procopio
 Type:  Bug  |   Status:  assigned
Component:  contrib.auth |  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mattia Procopio):

 * status:  new => assigned
 * owner:  nobody => Mattia Procopio


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

Re: [Django] #29216: Add the ZalgoScript filtration!

[Django]

#29216: Add the ZalgoScript filtration!
--+--
 Reporter:  Marat Mkhitaryan  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Template system   |  Version:  2.0
 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 Marat Mkhitaryan:

Old description:

> http://blog.portswigger.net/2018/03/unearthing-zalgoscript-with-
> visual.html
> Look:
>
> Z͌̈́̾a͊̈́l͊̿g̏̉͆o̾̚̚S̝̬ͅc̬r̯̼͇ͅi̼͖̜̭͔p̲̘̘̹͖t̠͖̟̹͓͇ͅ
>

> It looks like shit! They need filter these shit!

New description:

 http://blog.portswigger.net/2018/03/unearthing-zalgoscript-with-
 visual.html
 Look:

 Z͌̈́̾a͊̈́l͊̿g̏̉͆o̾̚̚S̝̬ͅc̬r̯̼͇ͅi̼͖̜̭͔p̲̘̘̹͖t̠͖̟̹͓͇ͅ


 It looks like shit! We need filter these shit!

--

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

[Django] #29216: Add the ZalgoScript filtration!

[Django]

#29216: Add the ZalgoScript filtration!
+
   Reporter:  Marat Mkhitaryan  |  Owner:  nobody
   Type:  New feature   | Status:  new
  Component:  Template system   |Version:  2.0
   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 |
+
 http://blog.portswigger.net/2018/03/unearthing-zalgoscript-with-
 visual.html
 Look:

 Z͌̈́̾a͊̈́l͊̿g̏̉͆o̾̚̚S̝̬ͅc̬r̯̼͇ͅi̼͖̜̭͔p̲̘̘̹͖t̠͖̟̹͓͇ͅ


 It looks like shit! They need filter these shit!

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

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

Re: [Django] #29215: Document potential change to behaviour of QuerySet methods when upgrading to Python 3.6

[Django]

#29215: Document potential change to behaviour of QuerySet methods when 
upgrading
to Python 3.6
-+-
 Reporter:  Matt Fisher  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  documentation| Triage Stage:
 |  Unreviewed
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)


Comment:

 This behavior has little to do with Python 3.6 itself.

 If you had query performing better on Python 2.7 than on Python 3 it's
 probably because you weren't using
 
[https://docs.python.org/2/using/cmdline.html?highlight=pythonhashseed#cmdoption-r
 a random hash seed] which is the default on Python 3. In other words, you
 were relying on a stable hash seed to build queries in a way that
 PostgreSQL query planner's would correctly optimize. If you had updated
 from 2.7 to Python 3.5 instead you would have hit the slow query issue
 from time to time when the interpreter chose an hash seed that made
 `list({'b__in', 'a'}) == ['b__in', 'a']`. In some way Python 3.6 allows
 you to reliably build your `WHERE` statement through kwargs ordering while
 it wasn't possible before.

 I guess we could add a section about the fact Python 3 has random hash
 seeding on by default and that may break code making assumptions about
 unordered data structures ordering. Maybe we should also suggest running
 Python 2.7 with the `-R` flag on when porting code?

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

[Django] #29215: Document potential change to behaviour of QuerySet methods when upgrading to Python 3.6

[Django]

#29215: Document potential change to behaviour of QuerySet methods when 
upgrading
to Python 3.6
-+-
   Reporter:  Matt   |  Owner:  nobody
  Fisher |
   Type: | Status:  new
  Cleanup/optimization   |
  Component: |Version:  2.0
  Documentation  |
   Severity:  Normal |   Keywords:  documentation
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Python 3.6 introduces
 [https://docs.python.org/3/whatsnew/3.6.html#whatsnew36-pep468 a change]
 that preserves the ordering of keyword arguments -
 [https://www.python.org/dev/peps/pep-0468/ PEP 468: Preserving Keyword
 Argument Order]

 Since this is not a difference between Python 2 and 3 per se, it is not
 mentioned in the [https://docs.djangoproject.com/en/1.11/topics/python3/
 “Porting to Python 3”] Django 1.11 topic page.

 Preserving keyword argument ordering can change the SQL produced by
 QuerySet methods that accept `**kwargs`, specifically .get, .filter, and
 .exclude, and potentially also .values, .annotate, .aggregate, .create,
 .get_or_create, .update, and .update_or_create.

 As an example,
 `.filter(b__in=some_qs, a=1)`
 could produce
 `... WHERE (a=1 AND b IN (SELECT …))` in Python < 3.6 and
 `... WHERE (b IN (SELECT …) AND a=1)` in Python >= 3.6.
 The query is semantically equivalent but the postgres query planner can
 produce dramatically different query plans and resultant performance if
 the query has a significant number of joins.

 We had one particular frequently-run query that ran in 2-3 seconds in
 Python 2, and 80+ seconds in Python 3.6. The problem was only apparent in
 production, and presented as severely degraded responsiveness from the
 postgres RDS database. The additional load on the database made most other
 queries take longer as well, which made it difficult to track down the
 cause as it was not obvious that any queries could have changed. To
 compound the problem, the different query execution caused many more temp
 block writes on the RDS instance, which burned through our IOPS burst
 balance and further degraded site performance. Because the query didn’t
 change semantically, all our automated tests passed and we didn’t see the
 issue until it was in production under full load. Googling the problem
 produced no good results, which suggests it is not common, but in need of
 a useful resource.

 People may be affected by this change when upgrading from Python 2.7 to
 Python 3.6+ using Django 1.x, in which case it would be helpful to have a
 warning in the [https://docs.djangoproject.com/en/1.11/topics/python3/
 1.11 porting topic], but it will also occur when people are upgrading from
 Python 3.[0-5] to 3.6+ while potentially using Django 2, in which case the
 porting topic is no longer in the current docs. Not sure what would be an
 appropriate place for a warning in this case.

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

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

Re: [Django] #29206: ValidationError when a reset password link contains a bad UIDB64 UUID (was: Validation Error and 500 when a reset password link contains a bad UIDB64 UUID)

[Django]

#29206: ValidationError when a reset password link contains a bad UIDB64 UUID
-+
 Reporter:  Mattia Procopio  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Tim Graham):

 * component:  Uncategorized => contrib.auth
 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


Old description:

> Our user model pk is a UUID, while making some tests trying to reset the
> password, we met a 500 because the encoded UUID is not decoded properly.
> Here's the URL:
> http://127.0.0.1:8000/reset/MTgiYWRiYmItZWNhYi00OTBiLThiMTMtYzg0MDUxMWRmOTVl/4u3-853c9fe868a403fa439f/
>
> and this is the traceback:
>
> {{{
> ValueError: invalid literal for int() with base 16:
> '18"adbbbecab490b8b13c840511df95e'
>   File "django/db/models/fields/__init__.py", line 2363, in to_python
> return uuid.UUID(value)
>   File "python3.6/uuid.py", line 141, in __init__
> int = int_(hex, 16)
>
> ValidationError: ['\'18"adbbb-ecab-490b-8b13-c840511df95e\' is not a
> valid UUID.']
>   File "django/core/handlers/exception.py", line 35, in inner
> response = get_response(request)
>   File "django/core/handlers/base.py", line 128, in _get_response
> response = self.process_exception_by_middleware(e, request)
>   File "django/core/handlers/base.py", line 126, in _get_response
> response = wrapped_callback(request, *callback_args,
> **callback_kwargs)
>   File "django/views/decorators/debug.py", line 76, in
> sensitive_post_parameters_wrapper
> return view(request, *args, **kwargs)
>   File "django/views/decorators/cache.py", line 44, in _wrapped_view_func
> response = view_func(request, *args, **kwargs)
>   File "django/contrib/auth/views.py", line 329, in
> password_reset_confirm
> user = UserModel._default_manager.get(pk=uid)
>   File "django/db/models/manager.py", line 82, in manager_method
> return getattr(self.get_queryset(), name)(*args, **kwargs)
>   File "django/db/models/query.py", line 397, in get
> num = len(clone)
>   File "django/db/models/query.py", line 254, in __len__
> self._fetch_all()
>   File "django/db/models/query.py", line 1179, in _fetch_all
> self._result_cache = list(self._iterable_class(self))
>   File "django/db/models/query.py", line 53, in __iter__
> results = compiler.execute_sql(chunked_fetch=self.chunked_fetch,
> chunk_size=self.chunk_size)
>   File "django/db/models/sql/compiler.py", line 1051, in execute_sql
> sql, params = self.as_sql()
>   File "django/db/models/sql/compiler.py", line 459, in as_sql
> where, w_params = self.compile(self.where) if self.where is not None
> else ("", [])
>   File "django/db/models/sql/compiler.py", line 391, in compile
> sql, params = node.as_sql(self, self.connection)
>   File "django/db/models/sql/where.py", line 80, in as_sql
> sql, params = compiler.compile(child)
>   File "django/db/models/sql/compiler.py", line 391, in compile
> sql, params = node.as_sql(self, self.connection)
>   File "django/db/models/lookups.py", line 161, in as_sql
> rhs_sql, rhs_params = self.process_rhs(compiler, connection)
>   File "django/db/models/lookups.py", line 260, in process_rhs
> return super().process_rhs(compiler, connection)
>   File "django/db/models/lookups.py", line 93, in process_rhs
> return self.get_db_prep_lookup(value, connection)
>   File "django/db/models/lookups.py", line 187, in get_db_prep_lookup
> [get_db_prep_value(value, connection, prepared=True)]
>   File "django/db/models/fields/__init__.py", line 2354, in
> get_db_prep_value
> value = self.to_python(value)
>   File "django/db/models/fields/__init__.py", line 2368, in to_python
> params={'value': value},
> }}}
>
> The error is raised when **user =
> UserModel._default_manager.get(pk=uid)** is executd, while I think a
> ValidationError is a proper exception I'm wondering if that couldn't be
> catched within that try/except. I feel is a bit weird getting a 500 if
> somebody tries to forge a URL for example.

New description:

 Our user model pk is a UUID, while making some tests trying to reset the
 password, we met a 500 because the encoded UUID is not decoded properly.
 Here's the URL:
 
http://127.0.0.1:8000/reset/MTgiYWRiYmItZWNhYi00OTBiLThiMTMtYzg0MDUxMWRmOTVl/4u3-853c9fe868a403fa439f/

 and this is the traceback:

 {{{
 ValueError: invalid literal for int() with base 16:
 '18"adbbbecab490b8b13c840511df95e'
   File 

Re: [Django] #29155: Using contains lookup with Substr causes modification of second parameter of Substr

[Django]

#29155: Using contains lookup with Substr causes modification of second 
parameter
of Substr
-+-
 Reporter:  norac89  |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | 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.798944b1c0bb5d8f119d3c0493de19d4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28668: Add ON CONFLICT support to QuerySet.bulk_create()

[Django]

#28668: Add ON CONFLICT support to QuerySet.bulk_create()
-+-
 Reporter:  Tom Forbes   |Owner:  Tom
 |  Forbes
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (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
-+-

Comment (by Дилян Палаузов):

 How essential is it, that objects inserted in the database, have their
 {{{._state.adding}}} and {{{._state.db}}} set?  The code from
 {{{bulk_create(..., on_conflict='ignore')}}} below is not called when
 ids=[], which happens when database does not return the IDs.

 {{{
 for obj_without_pk, pk in zip(objs_without_pk, ids):
 obj_without_pk.pk = pk
 obj_without_pk._state.adding = False
 obj_without_pk._state.db = self.db

 }}}

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

Re: [Django] #29199: Oracle backend won't connect if password contains '@'

[Django]

#29199: Oracle backend won't connect if password contains '@'
-+-
 Reporter:  Shane Allgeier   |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:"acfc650f2a6e4a79e80237eabfa923ea3a05d709" acfc650f]:
 {{{
 #!CommitTicketReference repository=""
 revision="acfc650f2a6e4a79e80237eabfa923ea3a05d709"
 Fixed #29199 -- Fixed crash when database user password contains @ sign on
 Oracle.

 Thanks Shane Allgeier for the report and 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/071.7c0cb9e602fca0a669a2efa86655e0a8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29147: Postgres JSONField missing to_python

[Django]

#29147: Postgres JSONField missing to_python
-+-
 Reporter:  Javier Buzzi |Owner:  Williams
 |  Mendez
 Type:  Bug  |   Status:  closed
Component:  contrib.postgres |  Version:  1.9
 Severity:  Normal   |   Resolution:  invalid
 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 Tim Graham):

 What behavior changes as a result of the patch?

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

Re: [Django] #29192: Docs on abstract base models say you can't override abstract fields

[Django]

#29192: Docs on abstract base models say you can't override abstract fields
-+-
 Reporter:  Marten Kenbeek   |Owner:  klee05
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  2.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"fbae9c0e023aea2666feb1603ece172548342ec1" fbae9c0e]:
 {{{
 #!CommitTicketReference repository=""
 revision="fbae9c0e023aea2666feb1603ece172548342ec1"
 [1.11.x] Fixed #29192 -- Removed inaccurate statement regarding overriding
 fields from abstract base classes.

 Partial backport of 22bcd3a1d88add6e4cf2c4451ede8d1ae142dedd from master
 }}}

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

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

Re: [Django] #29192: Docs on abstract base models say you can't override abstract fields

[Django]

#29192: Docs on abstract base models say you can't override abstract fields
-+-
 Reporter:  Marten Kenbeek   |Owner:  klee05
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  2.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | 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 ):

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


Comment:

 In [changeset:"22bcd3a1d88add6e4cf2c4451ede8d1ae142dedd" 22bcd3a1]:
 {{{
 #!CommitTicketReference repository=""
 revision="22bcd3a1d88add6e4cf2c4451ede8d1ae142dedd"
 Fixed #29192 -- Corrected docs regarding overriding fields from abstract
 base classes.
 }}}

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

Re: [Django] #29192: Docs on abstract base models say you can't override abstract fields

[Django]

#29192: Docs on abstract base models say you can't override abstract fields
-+-
 Reporter:  Marten Kenbeek   |Owner:  klee05
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  2.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"24066cc43005eb6c209fe543e1e8d00f730eb50b" 24066cc4]:
 {{{
 #!CommitTicketReference repository=""
 revision="24066cc43005eb6c209fe543e1e8d00f730eb50b"
 [2.0.x] Fixed #29192 -- Corrected docs regarding overriding fields from
 abstract base classes.

 Backport of 22bcd3a1d88add6e4cf2c4451ede8d1ae142dedd from master
 }}}

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

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

[Django] #29214: SQL-error when updating after annotating using subquery

[Django]

#29214: SQL-error when updating after annotating using subquery
-+-
   Reporter:  Oskar  |  Owner:  nobody
  Persson|
   Type:  Bug| Status:  new
  Component:  Database   |Version:  1.11
  layer (models, ORM)|   Keywords:  queryset
   Severity:  Normal |  annotations
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 An SQL-error is raised when updating a queryset which includes an
 annotation created using a subquery, which in turn also uses an
 annotation.


 {{{

 class Recursive(models.Model):
 name = models.CharField(max_length=10)
 link = models.IntegerField()
 parent = models.ForeignKey('self', models.CASCADE, null=True)

 rec1 = Recursive.objects.create(name="r1", link=1)
 rec2 = Recursive.objects.create(name="r2", link=1)
 rec3 = Recursive.objects.create(name="r11", parent=rec1, link=2)

 latest_parent =
 Recursive.objects.filter(link=OuterRef('parent_link')).order_by('id')

 Recursive.objects.filter(parent__isnull=False) \
 .annotate(parent_link=F('parent__link')) \
 .annotate(p=Subquery(latest_parent.values('pk')[:1])) \
 .update(parent_id=F('p'))
 }}}

 {{{
 Traceback (most recent call last):
   File "tests.py", line 88, in
 test_update_annotated_using_related_queryset
 .update(parent_id=F('p'))
   File "/git/django/django/db/models/query.py", line 647, in update
 rows = query.get_compiler(self.db).execute_sql(CURSOR)
   File "/git/django/django/db/models/sql/compiler.py", line 1204, in
 execute_sql
 cursor = super(SQLUpdateCompiler, self).execute_sql(result_type)
   File "/git/django/django/db/models/sql/compiler.py", line 899, in
 execute_sql
 raise original_exception
 OperationalError: no such column: T2.link
 }}}

 I've tried this in SQLite and MySQL in Django 1.11.11 and Django 2.0 using
 Python 3.6.0. All raising similar errors.

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

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

Re: [Django] #29184: TabularInline read-only fields ignore ModelForm Meta.labels and help_texts

[Django]

#29184: TabularInline read-only fields ignore ModelForm Meta.labels and 
help_texts
-+-
 Reporter:  David Sanders|Owner:  Danil
 |  Kozyatnikov
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  readonly,| Triage Stage:  Accepted
  help_texts, labels |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * needs_tests:  1 => 0


Comment:

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

Re: [Django] #29192: Docs on abstract base models say you can't override abstract fields

[Django]

#29192: Docs on abstract base models say you can't override abstract fields
-+-
 Reporter:  Marten Kenbeek   |Owner:  klee05
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:   | 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):

 * has_patch:  0 => 1
 * stage:  Unreviewed => Ready for checkin


Comment:

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

Re: [Django] #29147: Postgres JSONField missing to_python

[Django]

#29147: Postgres JSONField missing to_python
-+-
 Reporter:  Javier Buzzi |Owner:  Williams
 |  Mendez
 Type:  Bug  |   Status:  closed
Component:  contrib.postgres |  Version:  1.9
 Severity:  Normal   |   Resolution:  invalid
 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 Javier Buzzi):

 I added this (copy and paste from hstore.py)

 {{{
 --- a/django/contrib/postgres/fields/jsonb.py
 +++ b/django/contrib/postgres/fields/jsonb.py
 @@ -41,6 +41,14 @@ class JSONField(CheckFieldDefaultMixin, Field):
  self.encoder = encoder
  super().__init__(verbose_name, name, **kwargs)

 +def to_python(self, value):
 +if isinstance(value, str):
 +value = json.loads(value)
 +return value
 +
 +def value_to_string(self, obj):
 +return json.dumps(self.value_from_object(obj))
 +
  def db_type(self, connection):
  return 'jsonb'
 }}}
 ran the tests:


 {{{
 $ /django/tests/runtests.py postgres_tests.test_json --failfast
 --settings=mysettings
 Testing against Django installed in '/usr/local/lib/python3.6/site-
 packages/Django-2.1.dev20180313024248-py3.6.egg/django' with up to 4
 processes
 Creating test database for alias 'default'...
 Cloning test database for alias 'default'...
 Cloning test database for alias 'default'...
 Cloning test database for alias 'default'...
 Cloning test database for alias 'default'...
 System check identified no issues (0 silenced).
 ...
 --
 Ran 55 tests in 0.118s

 OK
 Destroying test database for alias 'default'...
 Destroying test database for alias 'default'...
 Destroying test database for alias 'default'...
 Destroying test database for alias 'default'...
 Destroying test database for alias 'default'...

 }}}

 Here are all the steps on how i got it to work:

 {{{
 $ docker run --rm -it python:3.6.4 bash
 apt-get update
 git clone https://github.com/django/django.git
 cd django
 sed -i "s/^exit 101$/exit 0/" /usr/sbin/policy-rc.d
 apt-get install -y libmemcached-dev postgresql vim postgresql-contrib
 python setup.py install
 pip install -rtests/requirements/py3.txt -rtests/requirements/postgres.txt
 echo "SECRET_KEY = 'hello'
 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.postgresql_psycopg2',
 'NAME': 'django',
 'USER': 'django',
 'PASSWORD': 'django',
 'HOST': 'localhost',
 'PORT': 5432,
 }
 }" > tests/mysettings.py
 echo "local   all all trust" >>
 /etc/postgresql/9.4/main/pg_hba.conf
 echo "diff --git a/django/contrib/postgres/fields/jsonb.py
 b/django/contrib/postgres/fields/jsonb.py
 index 3c27607..49b65ef 100644
 --- a/django/contrib/postgres/fields/jsonb.py
 +++ b/django/contrib/postgres/fields/jsonb.py
 @@ -41,6 +41,14 @@ class JSONField(CheckFieldDefaultMixin, Field):
  self.encoder = encoder
  super().__init__(verbose_name, name, **kwargs)

 +def to_python(self, value):
 +if isinstance(value, str):
 +value = json.loads(value)
 +return value
 +
 +def value_to_string(self, obj):
 +return json.dumps(self.value_from_object(obj))
 +
  def db_type(self, connection):
  return 'jsonb'

 " > mychanges.diff
 patch django/contrib/postgres/fields/jsonb.py mychanges.diff
 service postgresql start
 echo "set the password to 'django'"
 su postgres -c 'createuser --superuser django -P'
 /django/tests/runtests.py postgres_tests.test_json --failfast
 --settings=mysettings

 }}}

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

Re: [Django] #29204: Problems with Django and timezone

[Django]

#29204: Problems with Django and timezone
---+--
 Reporter:  ovalseven8 |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  2.0
 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 Tim Graham):

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


Comment:

 This is probably a lack of understanding of how Django works. See
 TicketClosingReasons/UseSupportChannels for ways to get help. If you
 confirm a bug in Django through those channels, please reopen the ticket
 and explain why Django is at fault.

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

Re: [Django] #29199: Oracle backend won't connect if password contains '@'

[Django]

#29199: Oracle backend won't connect if password contains '@'
-+-
 Reporter:  Shane Allgeier   |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


Comment:

 This doesn't qualify for a backport based on our
 [https://docs.djangoproject.com/en/dev/internals/release-process
 /#supported-versions supported versions policy].

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

Re: [Django] #29120: Document that the admin autocomplete requires the change permission of the related model

[Django]

#29120: Document that the admin autocomplete requires the change permission of 
the
related model
-+-
 Reporter:  Rodrigo Pinheiro |Owner:  Johannes
  Marques de Araújo  |  Hoppe
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 `raw_id_fields` also requires the change permission of the related object
 to view the list, so I don't see a problem with the current design of
 autocomplete fields. If a "view" permission is added (#8936) that could
 also be consulted for this check.

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

Re: [Django] #21408: Fallback to timesince produces erroneous translations in naturaltime

[Django]

#21408: Fallback to timesince produces erroneous translations in naturaltime
-+-
 Reporter:  676c7473@…   |Owner:
 |  Maximilian Merz
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  i18n l10n| Triage Stage:  Accepted
  translation|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Maximilian Merz):

 [https://github.com/django/django/pull/9777 pull request 9777] submitted

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

Re: [Django] #29213: Translations for autocomplete widget don't work for zh-hans and zh-hant

[Django]

#29213: Translations for autocomplete widget don't work for zh-hans and zh-hant
-+-
 Reporter:  dzhuang  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  2.0
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"59f39ccad8478c091161bf54046cd7b774614e62" 59f39cca]:
 {{{
 #!CommitTicketReference repository=""
 revision="59f39ccad8478c091161bf54046cd7b774614e62"
 [2.0.x] Fixed #29213 -- Fixed autocomplete widget's translations for zh-
 hans/zh-hant.

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

Re: [Django] #29213: Translations for autocomplete widget don't work for zh-hans and zh-hant

[Django]

#29213: Translations for autocomplete widget don't work for zh-hans and zh-hant
-+-
 Reporter:  dzhuang  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  2.0
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | 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 ):

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


Comment:

 In [changeset:"e17088a108e604cad23b000a83189fdd02a8a2f9" e17088a]:
 {{{
 #!CommitTicketReference repository=""
 revision="e17088a108e604cad23b000a83189fdd02a8a2f9"
 Fixed #29213 -- Fixed autocomplete widget's translations for zh-hans/zh-
 hant.
 }}}

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

[Django] #29213: Translations for autocomplete widget don't work for zh-hans and zh-hant

[Django]

#29213: Translations for autocomplete widget don't work for zh-hans and zh-hant
-+
   Reporter:  dzhuang|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  contrib.admin  |Version:  2.0
   Severity:  Release blocker|   Keywords:
   Triage Stage:  Ready for checkin  |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 Since `zh-cn` and `zh-tw` has been removed from i18n support,
 
[https://github.com/django/django/blob/3c71fb3909d4fdf6691712dfe84d7b7b8e9fcc35/django/contrib/admin/widgets.py#L374
 this line] should be updated so that JavaScript translations for `zh-hans`
 and `zh-hant` work.

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

Re: [Django] #21408: Fallback to timesince produces erroneous translations in naturaltime

[Django]

#21408: Fallback to timesince produces erroneous translations in naturaltime
-+-
 Reporter:  676c7473@…   |Owner:
 |  Maximilian Merz
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  i18n l10n| Triage Stage:  Accepted
  translation|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Maximilian Merz):

 * status:  new => assigned
 * owner:  nobody => Maximilian Merz


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