Re: [Django] #27060: Take indexes into account in inspectdb command

[Django]

#27060: Take indexes into account in inspectdb command
-+-
 Reporter:  Akshesh Doshi|Owner:  Pavel
 |  White
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  db-indexes   | Triage Stage:  Accepted
  inspectdb  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * needs_better_patch:  0 => 1


Comment:

 This ticket is about adding support for `Meta.indexes` to the `inspectdb`
 not about the `db_index` option. Mainly because it can be hard to ensure
 that an inspected index is exactly the same as an index created by Django
 (type, ordering, operator classes, `fillfactor` etc.). That's why we
 accepted a ticket to support `Meta.indexes` where these options may be
 included.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.bd0a556a9ccd0bd3d0734dd08eb40b4f%40djangoproject.com.

Re: [Django] #30984: Cache culling. (was: Cache culling)

[Django]

#30984: Cache culling.
-+-
 Reporter:  Martin Ennemoser |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Core (Cache system)  |  Version:  2.2
 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 felixxm):

 * status:  new => closed
 * component:  Uncategorized => Core (Cache system)
 * resolution:   => invalid


Comment:

 > I noticed that there is a cull() method that randomly deletes my cache
 files. This is horrible since my users don't get the cached results
 anymore and have to wait very long until they get the calculated result.
 > Don't you consider this cull() method dangerous?

 Cache is to cache values, and all cache system have limited capacity, so
 to create a space for new values we need to remove old entries, that's why
 culling is necessary. Cache backends implement their own culling strategy
 (see [https://docs.djangoproject.com/en/2.2/topics/cache/#cache-arguments
 documentation]). You can increase `MAX_ENTRIES`, but I think that you're
 using cache in a wrong way. Nevertheless I don't see here any issue in
 Django.

 Closing per TicketClosingReasons/UseSupportChannels

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.9809c9ce3e30acf8d4c141ea8e9fe0ee%40djangoproject.com.

Re: [Django] #30985: Error when adding a group in admin - "The database backend does not accept 0 as a value for AutoField". (was: Error when adding a group In admin - The database backend does not ac

[Django]

#30985: Error when adding a group in admin - "The database backend does not 
accept
0 as a value for AutoField".
-+-
 Reporter:  Juan Manuel  |Owner:  nobody
  Crescente  |
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  2.2
 Severity:  Normal   |   Resolution:
 |  worksforme
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

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

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

Re: [Django] #30985: Error when adding a group In admin - The database backend does not accept 0 as a value for AutoField.

[Django]

#30985: Error when adding a group In admin - The database backend does not 
accept 0
as a value for AutoField.
-+-
 Reporter:  Juan Manuel  |Owner:  nobody
  Crescente  |
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  2.2
 Severity:  Normal   |   Resolution:
 |  worksforme
 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:   => worksforme
 * component:  Uncategorized => contrib.admin
 * type:  Uncategorized => Bug


Comment:

 Thanks for this report, however described scenario works for me on MySQL.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.5cfbcd66f353371e49414db2a8318651%40djangoproject.com.

Re: [Django] #30966: Migration crashes due to foreign key issue, depending on otherwise irrelevant order on MySQL.

[Django]

#30966: Migration crashes due to foreign key issue, depending on otherwise
irrelevant order on MySQL.
-+-
 Reporter:  Peter Thomassen  |Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migration mySQL  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 Hasan, the changes in `django/db/migrations/state.py` from comment:7 are
 likely desired but the assertion in `Options` were more of a way to test
 which operation currently break this contract. From your submitted PR only
 three `migrations` tests were failing with these assertions including the
 one you added even on SQLite.

 Again, I suspect the cause is #27737 and the `TODO` in
 `AlterField.state_forwards`. The fact the rendering is delayed prevents
 `Token` from being refreshed adequately.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.90cc0548f9d27b3f4f05aeffb6a90ea2%40djangoproject.com.

Re: [Django] #30941: hasattr(request, '_cached_user') check no longer works

[Django]

#30941: hasattr(request, '_cached_user') check no longer works
-+
 Reporter:  Collin Anderson  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  Version:  master
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Carlton Gibson):

 Ooops. Sorry I didn't see the further conversation here before merging
 this this afternoon. Happy to discuss on the mailing list, and re-revert
 if we decide to go that way.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.65441d09689f9432af01a8d79c3e700c%40djangoproject.com.

[Django] #30985: Error when adding a group In admin - The database backend does not accept 0 as a value for AutoField.

[Django]

#30985: Error when adding a group In admin - The database backend does not 
accept 0
as a value for AutoField.
-+
   Reporter:  Juan Manuel Crescente  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |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  |
-+
 ValueError at /admin/auth/group/add/

 The database backend does not accept 0 as a value for AutoField.
 Request Method: POST
 Request URL:
 http://localhost:8000/admin/auth/group/add/?_to_field=id&_popup=1
 Django Version: 2.2.3
 Exception Type: ValueError
 Exception Value:
 The database backend does not accept 0 as a value for AutoField.
 Exception Location:
 /Users/juan/Documents/manu/dev/yas/venv3/lib/python3.7/site-
 packages/django/db/backends/mysql/operations.py in validate_autopk_value,
 line 181
 Python Executable:
 /Users/juan/Documents/manu/dev/yas/venv3/bin/python
 Python Version: 3.7.3
 Python Path:
 ['/Users/juan/Documents/manu/dev/yas',
  '/Users/juan/Documents/manu/dev/yas/venv3/lib/python37.zip',
  '/Users/juan/Documents/manu/dev/yas/venv3/lib/python3.7',
  '/Users/juan/Documents/manu/dev/yas/venv3/lib/python3.7/lib-dynload',
 
'/usr/local/Cellar/python/3.7.3/Frameworks/Python.framework/Versions/3.7/lib/python3.7',
  '/Users/juan/Documents/manu/dev/yas/venv3/lib/python3.7/site-packages']
 Server time:Wed, 13 Nov 2019 19:12:05 +

 in Django==2.2.3

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/056.9cb118a281d86912eac2dd4d38d07039%40djangoproject.com.

[Django] #30984: Cache culling

[Django]

#30984: Cache culling
+
   Reporter:  Martin Ennemoser  |  Owner:  nobody
   Type:  Uncategorized | Status:  new
  Component:  Uncategorized |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 |
+
 I have an endpoint that needs very long to create a response since the
 calculation of it takes very long. My approach was to cache the result in
 a file cache and return the cached result to the user. From time to time I
 asynchronously recalculate the result and update the cache. Since I don't
 want to let the cache expire, I set the expire argument to None. The first
 time, that worked well. But after a couple of hours, I found out that the
 cache files were deleted randomly. Looking into the code of the
 FileBasedCache class
 
https://github.com/django/django/blob/master/django/core/cache/backends/filebased.py
 I noticed that there is a cull() method that randomly deletes my cache
 files. This is horrible since my users don't get the cached results
 anymore and have to wait very long until they get the calculated result.
 Don't you consider this cull() method dangerous?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/048.cc81c22047625dead4258caf0445ecc5%40djangoproject.com.

Re: [Django] #30983: Exception traceback fails due to subsequent exceptions when using the Jinja template backend and Jinja>=2.10.2

[Django]

#30983: Exception traceback fails due to subsequent exceptions when using the 
Jinja
template backend and Jinja>=2.10.2
-+--
 Reporter:  Barak Shohat |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  2.2
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by Barak Shohat):

 Agreed, the patch on that PR will resolve the cascading exceptions. Though
 not clear where the incorrect line number info is coming from.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.cd9824b339c79fb7f2f2dd4f780f31b9%40djangoproject.com.

Re: [Django] #30983: Exception traceback fails due to subsequent exceptions when using the Jinja template backend and Jinja>=2.10.2

[Django]

#30983: Exception traceback fails due to subsequent exceptions when using the 
Jinja
template backend and Jinja>=2.10.2
-+--
 Reporter:  Barak Shohat |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  2.2
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by Simon Charette):

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


Comment:

 I think this is a duplicate of #30405
 [https://github.com/django/django/pull/11886#issuecomment-553358279 based
 on this comment].

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.2fe5df34828b1b3bc84730acbb697f2b%40djangoproject.com.

Re: [Django] #30983: Exception traceback fails due to subsequent exceptions when using the Jinja template backend and Jinja>=2.10.2

[Django]

#30983: Exception traceback fails due to subsequent exceptions when using the 
Jinja
template backend and Jinja>=2.10.2
-+--
 Reporter:  Barak Shohat |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  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
-+--
Changes (by Barak Shohat):

 * cc: Barak Shohat (added)
 * type:  Uncategorized => Bug
 * component:  Uncategorized => Template system


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.dc58298bbba229d974f58f13493ec14e%40djangoproject.com.

[Django] #30983: Exception traceback fails due to subsequent exceptions when using the Jinja template backend and Jinja>=2.10.2

[Django]

#30983: Exception traceback fails due to subsequent exceptions when using the 
Jinja
template backend and Jinja>=2.10.2
-+
   Reporter:  bazzisoft  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |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  |
-+
 Jinja 2.10.2 introduces a new traceback system per their release docs:

 Version 2.10.2 Released 2019-10-04
 - Use Python 3.7’s better traceback support to avoid a core dump when
 using debug builds of Python 3.7.

 This appears to cause source code lines to be incorrectly reported in some
 template tracebacks, causing errors like the following:

 SAMPLE TEMPLATE:
 {{{
 {% extends 'accounts/base.html' %}
 {% block accounts_content %}
   {% block password_reset %}
 
   {{ block.super }}   {# ERROR IS HERE - `block` is not
 defined #}
   {{ crispy(form) }}
   
 
   {% endblock %}
 {% endblock %}
 }}}

 WEB SERVER TRACEBACK:
 {{{
 Traceback (most recent call last):
   File "D:\PROJECTS\DEVEL\hst\hstprod\venv\lib\site-
 packages\django\core\handlers\exception.py", line 34, in inner
 response = get_response(request)
   File "D:\PROJECTS\DEVEL\hst\hstprod\venv\lib\site-
 packages\django\core\handlers\base.py", line 145, in _get_response
 response = self.process_exception_by_middleware(e, request)
   File "D:\PROJECTS\DEVEL\hst\hstprod\venv\lib\site-
 packages\django\core\handlers\base.py", line 143, in _get_response
 response = response.render()
   File "D:\PROJECTS\DEVEL\hst\hstprod\venv\lib\site-
 packages\django\template\response.py", line 106, in render
 self.content = self.rendered_content
   File "D:\PROJECTS\DEVEL\hst\hstprod\venv\lib\site-
 packages\django\template\response.py", line 83, in rendered_content
 content = template.render(context, self._request)
   File "D:\PROJECTS\DEVEL\hst\hstprod\venv\lib\site-
 packages\django\template\backends\jinja2.py", line 71, in render
 return self.template.render(context)
   File "D:\PROJECTS\DEVEL\hst\hstprod\venv\lib\site-
 packages\jinja2\asyncsupport.py", line 76, in render
 return original_render(self, *args, **kwargs)
   File "D:\PROJECTS\DEVEL\hst\hstprod\venv\lib\site-
 packages\jinja2\environment.py", line 1008, in render
 return self.environment.handle_exception(exc_info, True)
   File "D:\PROJECTS\DEVEL\hst\hstprod\venv\lib\site-
 packages\jinja2\environment.py", line 780, in handle_exception
 reraise(exc_type, exc_value, tb)
   File "D:\PROJECTS\DEVEL\hst\hstprod\venv\lib\site-
 packages\jinja2\_compat.py", line 37, in reraise
 raise value.with_traceback(tb)
   File
 
"D:\PROJECTS\DEVEL\hst\hstprod\hstprod\apps\accounts\jinja2\accounts\password_reset_form.html",
 line 1, in top-level template code
 {% extends 'accounts/base.html' %}
   File "D:\PROJECTS\DEVEL\hst\hstprod\venv\lib\site-
 packages\jinja2\environment.py", line 1005, in render
 return concat(self.root_render_func(self.new_context(vars)))
   File
 
"D:\PROJECTS\DEVEL\hst\hstprod\hstprod\apps\accounts\jinja2\accounts\password_reset_form.html",
 line 14, in root
   File
 
"D:\PROJECTS\DEVEL\hst\hstprod\hstprod\apps\accounts\jinja2\accounts\base.html",
 line 14, in root
   File "D:\PROJECTS\DEVEL\hst\hstprod\hstprod\jinja2\base.html", line 13,
 in root
 
   File "D:\PROJECTS\DEVEL\hst\hstprod\hstprod\jinja2\base.html", line 92,
 in block_body
   File "D:\PROJECTS\DEVEL\hst\hstprod\hstprod\jinja2\base.html", line 105,
 in block_page_surface
   File "D:\PROJECTS\DEVEL\hst\hstprod\hstprod\jinja2\base.html", line 142,
 in block_mainpage
   File "D:\PROJECTS\DEVEL\hst\hstprod\hstprod\jinja2\base.html", line 167,
 in block_maincontent
   File
 
"D:\PROJECTS\DEVEL\hst\hstprod\hstprod\apps\accounts\jinja2\accounts\base.html",
 line 22, in block_content
   File
 
"D:\PROJECTS\DEVEL\hst\hstprod\hstprod\apps\accounts\jinja2\accounts\password_reset_form.html",
 line 22, in block_accounts_content
   File
 
"D:\PROJECTS\DEVEL\hst\hstprod\hstprod\apps\accounts\jinja2\accounts\password_reset_form.html",
 line 34, in block_password_reset
   File "D:\PROJECTS\DEVEL\hst\hstprod\venv\lib\site-
 packages\jinja2\environment.py", line 430, in getattr
 return getattr(obj, attribute)
 jinja2.exceptions.UndefinedError: 'block' is undefined

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "D:\PROJECTS\DEVEL\hst\hstprod\venv\lib\site-
 packages\django\core\handlers\exception.py", line 34, in inner
 response = get_response(request)
   File "D:

Re: [Django] #6148: Add generic support for database schemas

[Django]

#6148: Add generic support for database schemas
-+-
 Reporter:  Ian Kelly|Owner:  Anssi
 |  Kääriäinen
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle postgresql| Triage Stage:  Accepted
  mysql schemas  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Asif Saifuddin Auvi):

 Replying to [comment:181 Christian González]:
 > Is there any chance supporting Oracle too? I have exactly this use case:
 >
 > Using a different (read-only) Oracle user to access a production
 database read-only. This user gets his own schema, and I have to grant
 access to the production schema too using Oracle. Now I plan to create a
 REST API using Django/DRF for this (proprietary) database - but I would
 have to add the schema to every Meta.db_table in each model.
 > It would be convenient to have something like a SCHEMA setting in
 DATABASES working for Oracle too.
 >
 > I think I'm not capable of providing a production quality patch for
 Django myself, just maybe help a bit.
 >
 > As stated before - should this be discussed in a separate ticket?

 you can check this patch for some implementation idea
 https://github.com/django/django/pull/6162

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.0cb9e45355b7d567f7519a16a498b540%40djangoproject.com.

Re: [Django] #30941: hasattr(request, '_cached_user') check no longer works

[Django]

#30941: hasattr(request, '_cached_user') check no longer works
-+
 Reporter:  Collin Anderson  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  Version:  master
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Carlton Gibson ):

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


Comment:

 In [changeset:"6e99585c19290fb9bec502cac8210041fdb28484" 6e99585c]:
 {{{
 #!CommitTicketReference repository=""
 revision="6e99585c19290fb9bec502cac8210041fdb28484"
 Fixed #30941 -- Reverted "Simplified AuthenticationMiddleware a bit."

 This reverts commit 2f010795e690550c8c6f56b3924c0f629cacb33b.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.af5b78aa81aa748eda622b8e3cc8a5ba%40djangoproject.com.

Re: [Django] #29157: Allow querying for distinct values in JSONField lists

[Django]

#29157: Allow querying for distinct values in JSONField lists
---+
 Reporter:  Hrishikesh Barman  |Owner:  (none)
 Type:  New feature|   Status:  new
Component:  contrib.postgres   |  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 Fabian Köster):

 * cc: Fabian Köster (added)


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

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

Re: [Django] #23433: Django installs /usr/bin/django-admin and /usr/bin/django-admin.py

[Django]

#23433: Django installs /usr/bin/django-admin and /usr/bin/django-admin.py
-+-
 Reporter:  Arfrever |Owner:  Jon
 Type:   |  Dufresne
  Cleanup/optimization   |   Status:  assigned
Component:  Packaging|  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 Jon Dufresne):

 * needs_better_patch:  1 => 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.5f627806c77ad41153aa80a4735491e3%40djangoproject.com.

Re: [Django] #21238: `ImageFieldFile.url` raises an AttributeError exception after retrieving it from cache

[Django]

#21238: `ImageFieldFile.url` raises an AttributeError exception after 
retrieving it
from cache
-+-
 Reporter:  Pierre Dulac |Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  assigned
Component:  Core (Cache system)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  imagefield, cache| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Hasan Ramezani):

 * needs_better_patch:  1 => 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.69e30933193d854f07bd7002b24f6765%40djangoproject.com.

Re: [Django] #21238: `ImageFieldFile.url` raises an AttributeError exception after retrieving it from cache

[Django]

#21238: `ImageFieldFile.url` raises an AttributeError exception after 
retrieving it
from cache
-+-
 Reporter:  Pierre Dulac |Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  assigned
Component:  Core (Cache system)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  imagefield, cache| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * cc: Tim Graham (removed)


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.f14aa181362c7556d100317f804837a5%40djangoproject.com.

Re: [Django] #3237: [patch] CIDR in INTERNAL_IPS

[Django]

#3237: [patch] CIDR  in INTERNAL_IPS
-+-
 Reporter:  Jeremy Dunck |Owner:  nobody
   |
 Type:  enhancement  |   Status:  closed
Component:  Core (Other) |  Version:
 Severity:  normal   |   Resolution:  wontfix
 Keywords:  CIDR INTERNAL_IPS| Triage Stage:  Design
 |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Fabian Köster):

 Right, your solution is much easier. Thanks!

 Replying to [comment:12 Nick Pope]:
 > Replying to [comment:10 Fabian Köster]:
 >
 > Why overcomplicate things? You can do the following without any custom
 classes:
 >
 > {{{#!python
 > import ipaddress
 >
 > INTERNAL_IPS = ['127.0.0.1', *map(str,
 ipaddress.ip_network('172.0.0.0/24'))]
 > }}}
 >
 > Granted for `172.0.0.0/8` this is a bad idea, but then you should
 probably constrain your range of addresses!

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/089.c7bfb664185a4961129b5c9721cf89ae%40djangoproject.com.

Re: [Django] #23433: Django installs /usr/bin/django-admin and /usr/bin/django-admin.py

[Django]

#23433: Django installs /usr/bin/django-admin and /usr/bin/django-admin.py
-+-
 Reporter:  Arfrever |Owner:  Jon
 Type:   |  Dufresne
  Cleanup/optimization   |   Status:  assigned
Component:  Packaging|  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 felixxm):

 * owner:  nobody => Jon Dufresne
 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1
 * status:  new => assigned
 * stage:  Someday/Maybe => Accepted


Comment:

 [https://github.com/django/django/pull/12009 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.e23db51a1bae40cce979634c3d341755%40djangoproject.com.

Re: [Django] #30966: Migration crashes due to foreign key issue, depending on otherwise irrelevant order on MySQL.

[Django]

#30966: Migration crashes due to foreign key issue, depending on otherwise
irrelevant order on MySQL.
-+-
 Reporter:  Peter Thomassen  |Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migration mySQL  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Hasan Ramezani):

 Sure, I can check it again.
 Just for confirmation, Should I fix assertaion failures based on Simon's
 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.4667d2df4fe30fb84e5dbceb634c8894%40djangoproject.com.

Re: [Django] #30966: Migration crashes due to foreign key issue, depending on otherwise irrelevant order on MySQL.

[Django]

#30966: Migration crashes due to foreign key issue, depending on otherwise
irrelevant order on MySQL.
-+-
 Reporter:  Peter Thomassen  |Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migration mySQL  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * needs_better_patch:  0 => 1


Comment:

 Simon, thanks for an investigation! I agree that we should try to address
 the main issue.

 Hasan, Can you take a 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.4bc99e7fea09125483088745641c5011%40djangoproject.com.

Re: [Django] #21238: `ImageFieldFile.url` raises an AttributeError exception after retrieving it from cache

[Django]

#21238: `ImageFieldFile.url` raises an AttributeError exception after 
retrieving it
from cache
-+-
 Reporter:  Pierre Dulac |Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  assigned
Component:  Core (Cache system)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  imagefield, cache| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.75102528336e3c7fcb2135814beb99ad%40djangoproject.com.

Re: [Django] #30980: admin.E130 (duplicate __name__ attributes of actions) should specify which were duplicated. (was: admin.E130 (duplicate __name__ attributes of actions) should specify which were d

[Django]

#30980: admin.E130 (duplicate __name__ attributes of actions) should specify 
which
were duplicated.
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.admin |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by felixxm):

 * easy:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 Agreed, we can add names of duplicated actions to this message.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.41d2201275e6d5649b80369f402c3baf%40djangoproject.com.

Re: [Django] #30971: Query.resolve_lookup_value coerces value of type list to tuple

[Django]

#30971: Query.resolve_lookup_value coerces value of type list to tuple
-+-
 Reporter:  George Marshall  |Owner:  George
 |  Marshall
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 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 Mariusz Felisiak ):

 In [changeset:"8be79984dce7d819879a6e594ca69c5f95a08378" 8be79984]:
 {{{
 #!CommitTicketReference repository=""
 revision="8be79984dce7d819879a6e594ca69c5f95a08378"
 Fixed #30971 -- Prevented Query.resolve_lookup_value() from coercing list
 values to tuples.

 Regression in 8a281aa7fe76a9da2284f943964a9413697cff1f.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.202ed6048e203697679c58c051db83ab%40djangoproject.com.

Re: [Django] #30971: Query.resolve_lookup_value coerces value of type list to tuple

[Django]

#30971: Query.resolve_lookup_value coerces value of type list to tuple
-+-
 Reporter:  George Marshall  |Owner:  George
 |  Marshall
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"fa6076daf460df2c2c5ff9f62862f050bc4427f4" fa6076da]:
 {{{
 #!CommitTicketReference repository=""
 revision="fa6076daf460df2c2c5ff9f62862f050bc4427f4"
 [3.0.x] Fixed #30971 -- Prevented Query.resolve_lookup_value() from
 coercing list values to tuples.

 Regression in 8a281aa7fe76a9da2284f943964a9413697cff1f.

 Backport of 8be79984dce7d819879a6e594ca69c5f95a08378 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.1078eb369e52d52645d3a11f754d0e8f%40djangoproject.com.

Re: [Django] #30981: Admin changelist crashes when using F() and OrderBy() expressions in the ModelAdmin's admin_order_field. (was: Admin changelist crashes when using query expression in the ModelAdm

[Django]

#30981: Admin changelist crashes when using F() and OrderBy() expressions in the
ModelAdmin's admin_order_field.
---+
 Reporter:  Petr Dlouhý|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by felixxm):

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


Comment:

 Thanks for this report, we have here two issues. First, Admin's changelist
 crashes when using a `F()` expression in `admin_order_field`, we can fix
 this easily but checking `resolve_expression` instead of `as_sql`, e.g.
 {{{
 diff --git a/django/contrib/admin/views/main.py
 b/django/contrib/admin/views/main.py
 index 2f0e915d5e..f8b3015fb8 100644
 --- a/django/contrib/admin/views/main.py
 +++ b/django/contrib/admin/views/main.py
 @@ -308,7 +308,7 @@ class ChangeList:
  order_field = self.get_ordering_field(field_name)
  if not order_field:
  continue  # No 'admin_order_field', skip it
 -if hasattr(order_field, 'as_sql'):
 +if hasattr(order_field, 'resolve_expression'):
  # order_field is an expression.
  ordering.append(order_field.desc() if pfx == '-'
 else order_field.asc())
  # reverse order if order_field has already "-" as
 prefix
 }}}
 Second issue with `F('sum_amount').desc(nulls_last=True)` is related with
 the fact that this is an instance of an `OrderBy()` expression, so
 `.asc()` and `.desc()` don't return new instances of an `OrderBy()`.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.1cf6e5bf188d4c47e081d7d1f372c1e7%40djangoproject.com.