Re: [Django] #31289: system checks: admin.E002 could provide a hint but doesn't

[Django]

#31289: system checks: admin.E002 could provide a hint but doesn't
-+-
 Reporter:  Keryn Knight |Owner:  Sanskar
 Type:   |  Jaiswal
  Cleanup/optimization   |   Status:  assigned
Component:  Core (System |  Version:  3.0
  checks)|
 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 Sanskar Jaiswal):

 * owner:  nobody => Sanskar Jaiswal
 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.560a557608ce5502e1c602c4282752e9%40djangoproject.com.

Re: [Django] #31185: fields.E310-E311 should take into account UniqueConstraints without conditions.

[Django]

#31185: fields.E310-E311 should take into account UniqueConstraints without
conditions.
-+-
 Reporter:  Pavel Garkin |Owner:  Ahmad
 |  Abdallah
 Type:  Bug  |   Status:  assigned
Component:  Core (System |  Version:  master
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:  UniqueConstraint | Triage Stage:  Accepted
  unique_together E310 E311  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Ahmad Abdallah):

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

Re: [Django] #30581: Allow constraints to be used for validation (in Python)

[Django]

#30581: Allow constraints to be used for validation (in Python)
-+-
 Reporter:  Carlton Gibson   |Owner:  Sanskar
 |  Jaiswal
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  constraints, | Triage Stage:  Accepted
  validation |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 FWIW I started exploring the above idea and published
 [https://github.com/django/django/compare/master...charettes:constraints-
 validation my changes] which pass most of the test suite but still require
 a bit of polishing.

 In the light of the current barrage of issues related to checks that are
 not `UniqueConstraint` aware I think the `Constraint.auto_created`
 creation by `Field.unique` and `Model.Meta.unique_together` has merits as
 it would allow all of the ''unicity'' checks to be performed against
 `_meta.constraints` (or the newly added `total_unique_constraints`)
 instead of combining the three APIs all over the place.

-- 
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.5fa6933273c34abae38863c027cf947b%40djangoproject.com.

Re: [Django] #31185: fields.E310-E311 should take into account UniqueConstraints without conditions.

[Django]

#31185: fields.E310-E311 should take into account UniqueConstraints without
conditions.
-+-
 Reporter:  Pavel Garkin |Owner:  Ahmad
 |  Abdallah
 Type:  Bug  |   Status:  assigned
Component:  Core (System |  Version:  master
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:  UniqueConstraint | Triage Stage:  Accepted
  unique_together E310 E311  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Ahmad Abdallah):

 [https://github.com/django/django/pull/12477 Patch] submitted. Let me know
 what i need to improve. I haven't written a test it but I tested it on the
 code snippet posted above and it worked

-- 
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.892e6f5fb907a225ecf51402d992f93f%40djangoproject.com.

Re: [Django] #31285: Inherited model doesn't correctly order by "-pk" when specified on Parent.Meta.ordering

[Django]

#31285: Inherited model doesn't correctly order by "-pk" when specified on
Parent.Meta.ordering
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:  Bug  |   Status:  new
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 Simon Charette):

 I would expect `Parent.meta.ordering = ["id"]` to result in `ORDER BY
 "myapp_parent"."id"` while `Parent.meta.ordering = ["pk"]` results in
 `ORDER BY "myapp_child"."parent_ptr_id"`.

 Isn't that the case right now?

-- 
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.65ef383739cb227190aa6f6a9a8a2535%40djangoproject.com.

Re: [Django] #28919: Add support for Common Table Expression (CTE) queries

[Django]

#28919: Add support for Common Table Expression (CTE) queries
-+-
 Reporter:  Daniel Miller|Owner:  Moses
 |  Mugisha
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  QuerySet.extra   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Timothy Schilling):

 * cc: Timothy Schilling (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.76a4cfad10e06d3b791ba5367d2df905%40djangoproject.com.

Re: [Django] #30422: Temporary files do not get deleted on canceled upload request.

[Django]

#30422: Temporary files do not get deleted on canceled upload request.
-+-
 Reporter:  drutalj  |Owner:  Sanskar
 |  Jaiswal
 Type:  Bug  |   Status:  assigned
Component:  File |  Version:  master
  uploads/storage|
 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 Sanskar Jaiswal):

 * owner:  (none) => Sanskar Jaiswal
 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.0870bcd4cecb8ef45b91e348cc0be2ca%40djangoproject.com.

Re: [Django] #31290: Unable to runserver - python manage.py runserver

[Django]

#31290: Unable to runserver - python manage.py runserver
---+--
 Reporter:  batistalucash  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  3.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 Carlton Gibson):

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


Comment:

 This isn't a support channel. See TicketClosingReasons/UseSupportChannels.

 Passing a string as the view to `url()` was deprecated in Django 1.8
 https://docs.djangoproject.com/en/3.0/releases/1.8/#passing-a-string-as-
 view-to-url.

 Review the django.urls docs:
 https://docs.djangoproject.com/en/3.0/ref/urls/

-- 
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.6894a54152f1d773fff0e31dda5a0c91%40djangoproject.com.

[Django] #31290: Unable to runserver - python manage.py runserver

[Django]

#31290: Unable to runserver - python manage.py runserver
-+
   Reporter:  batistalucash  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  3.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  |
-+
 When I run server, I get the following error:

 raise TypeError('view must be a callable or a list/tuple in the case of
 include().')
 TypeError: view must be a callable or a list/tuple in the case of
 include().

 I have tried to add **include** to ''from django.urls import path'', but
 it did not work. Please help.

 More information below:

 urls.py file
 {{{
 from django.contrib import admin
 from django.urls import path

 urlpatterns = [
 path('admin', admin.site.urls),
 path('index', 'store.views.index', name='index'),
 ]
 }}}

 (book1) C:\Users\LucasBatistadosSanto\Desktop\Python\bookstore>py -m
 django --version
 3.0.3

 (book1) C:\Users\LucasBatistadosSanto\Desktop\Python\bookstore>python -V
 Python 3.7.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.6fabdc95bf4f9584540d1ff396cbdffc%40djangoproject.com.

Re: [Django] #31289: system checks: admin.E002 could provide a hint but doesn't

[Django]

#31289: system checks: admin.E002 could provide a hint but doesn't
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (System checks)  |  Version:  3.0
 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 Carlton Gibson):

 * type:  New feature => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 OK, fair enough. Got bandwidth for a 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/067.e17f3ac583483ff07821e7cc4542de0e%40djangoproject.com.

Re: [Django] #30040: Use a default permission name in docs examples to avoid confusion

[Django]

#30040: Use a default permission name in docs examples to avoid confusion
-+-
 Reporter:  Adrian Samatan   |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  2.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  template | Triage Stage:  Ready for
  permissions documentation  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson ):

 In [changeset:"a73489f162003472708887fac9b98987af6464fd" a73489f1]:
 {{{
 #!CommitTicketReference repository=""
 revision="a73489f162003472708887fac9b98987af6464fd"
 [3.0.x] Fixed #30040 -- Used default permission name in docs examples to
 avoid confusion.

 Backport of b7795d7673f51daf288ac80616ef69b05918ca6b 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/066.bc666bd53a86017762cf628f24fce5f9%40djangoproject.com.

Re: [Django] #30040: Use a default permission name in docs examples to avoid confusion

[Django]

#30040: Use a default permission name in docs examples to avoid confusion
-+-
 Reporter:  Adrian Samatan   |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  2.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  template | Triage Stage:  Ready for
  permissions documentation  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson ):

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


Comment:

 In [changeset:"b7795d7673f51daf288ac80616ef69b05918ca6b" b7795d76]:
 {{{
 #!CommitTicketReference repository=""
 revision="b7795d7673f51daf288ac80616ef69b05918ca6b"
 Fixed #30040 -- Used default permission name in docs examples to avoid
 confusion.
 }}}

-- 
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.1aff7cb96366c7276c34b11c78d4cbf0%40djangoproject.com.

[Django] #31289: system checks: admin.E002 could provide a hint but doesn't

[Django]

#31289: system checks: admin.E002 could provide a hint but doesn't
+
   Reporter:  Keryn Knight  |  Owner:  nobody
   Type:  New feature   | Status:  new
  Component:  Core (System checks)  |Version:  3.0
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  0 |
+
 Currently the output is:

 {{{
 myapp.MyCustomUserModel: (auth.E002) The field named as the
 'USERNAME_FIELD' for a custom user model must not be included in
 'REQUIRED_FIELDS'.
 }}}

 because I accidentally had:
 {{{
 USERNAME_FIELD = "email"
 EMAIL_FIELD = "email"
 REQUIRED_FIELDS = (USERNAME_FIELD, "full_name",)
 }}}

 Ignoring the fact that Django **knows** it's wrong to have it in there,
 and could easily just skip it or warn if it's not set, it doesn't make use
 of the hints available in system checks.

 I'd like to suggest that a hint could be provided which says which field
 it's moaning about, something like (open to better wording):
 {{{
 HINT: Your username field is currently set to "email", you should remove
 "email" from your required fields definition.
 }}}

 It's a stupidly little thing, but having not had to make a custom user
 from scratch for a while, my eyes glazed over the **not** in ` must not be
 ` and I was confused for all of 2 minutes before actually reading it
 properly.

-- 
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/052.f6fa64db0208d158df8eff8c5eff%40djangoproject.com.

Re: [Django] #31287: Rename mark_safe and "safe" template filters to something less safe sounding

[Django]

#31287: Rename mark_safe and "safe" template filters to something less safe
sounding
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 Yeah, look... I see it... But without a consensus for the change on the
 mailing list I don't see grounds for a ticket. The case needs to be made
 there.
 Pending something like that, I don't feel we can just bypass the list and
 Accept a ticket here.
 I hope that makes sense.

-- 
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.25d43ee666d929e0a216faaa4038cc3d%40djangoproject.com.

Re: [Django] #31287: Rename mark_safe and "safe" template filters to something less safe sounding

[Django]

#31287: Rename mark_safe and "safe" template filters to something less safe
sounding
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz):

 Meh... You will annoy thousands of devs having to rename multiple
 occurrences of those names, with IMHO a very small gain. EIther the
 developer is sensible to security coding and she's probably already
 careful about those, or the developer doesn't care and just wants to see
 its string be shown properly, whatever the name of the function is.
 TL;DR I'm not convinced.

-- 
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.a2d26bea82a3012d9e8d49f2e32642c5%40djangoproject.com.

Re: [Django] #31224: Add asynchronous views.

[Django]

#31224: Add asynchronous views.
--+-
 Reporter:  felixxm   |Owner:  Andrew Godwin
 Type:  New feature   |   Status:  assigned
Component:  Core (Other)  |  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
--+-

Comment (by Mariusz Felisiak ):

 In [changeset:"1e858adf7fabdeb98f95503d30ed6769a08c44b2" 1e858adf]:
 {{{
 #!CommitTicketReference repository=""
 revision="1e858adf7fabdeb98f95503d30ed6769a08c44b2"
 Refs #31224 -- Added BaseHandler.check_response().
 }}}

-- 
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.2611d0a9e95542a01411424ebed9ccb5%40djangoproject.com.

Re: [Django] #31286: Database specific fields checks should be databases aware.

[Django]

#31286: Database specific fields checks should be databases aware.
-+-
 Reporter:  Hongtao Ma   |Owner:  Hongtao
 |  Ma
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Simon Charette):

 * stage:  Accepted => Ready for checkin


Comment:

 Thanks for the patch @Taoup!

-- 
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.df763dd234bfe655671c05a74b42b629%40djangoproject.com.

Re: [Django] #31276: Add 'flush' option to only clear non-empty tables

[Django]

#31276: Add 'flush' option to only clear non-empty tables
-+-
 Reporter:  Adam (Chainz)|Owner:  jonatron
  Johnson|
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by jonatron):

 The sqlite problem can be fixed using the same chunking as is in
 _quote_params_for_last_executed_query.
 I can't explain sqlite's performance.

 sqlite
 1000 tables with patch
 Ran 5 tests in 0.237s
 Ran 5 tests in 0.345s
 Ran 5 tests in 0.288s
 Ran 5 tests in 0.257s
 Ran 5 tests in 0.240s

 1000 tables without patch

 Ran 5 tests in 55.617s
 Ran 5 tests in 57.577s
 Ran 5 tests in 55.242s

 900 tables without patch
 Ran 5 tests in 45.796s

 800 tables without patch
 Ran 5 tests in 35.795s

 600 tables without patch
 Ran 5 tests in 20.521s

 550 tables without patch
 Ran 5 tests in 19.025s

 500 tables without patch
 Ran 5 tests in 3.049s

 400 tables without patch
 Ran 5 tests in 2.068s

 200 tables without patch
 Ran 5 tests in 0.612s

-- 
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.2f1fb964cb6220718926eacdf1e6523e%40djangoproject.com.

Re: [Django] #31276: Add 'flush' option to only clear non-empty tables

[Django]

#31276: Add 'flush' option to only clear non-empty tables
-+-
 Reporter:  Adam (Chainz)|Owner:  jonatron
  Johnson|
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felixxm):

 About SQLite, I mentioned this in my
 [https://code.djangoproject.com/ticket/31276#comment:3 comment] ''"... the
 database's limit on the number of query parameters"'' (999 on SQLite).

-- 
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.6f83a2f46500a56273c746fbb3cbc2ab%40djangoproject.com.

Re: [Django] #31276: Add 'flush' option to only clear non-empty tables

[Django]

#31276: Add 'flush' option to only clear non-empty tables
-+-
 Reporter:  Adam (Chainz)|Owner:  jonatron
  Johnson|
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by jonatron):

 I've been benchmarking with 1000 tables and 5 tests. You'll notice sqlite
 has a problem with too many tables. Also the query for sqlite needs to be:
 {{{select * from ( SELECT '{}' AS has_rows FROM {} LIMIT 1 )}}}
 instead of
 {{{( SELECT '{}' AS has_rows FROM {} LIMIT 1 )}}}

 postgres

 current behaviour
 Ran 5 tests in 1.538s
 Ran 5 tests in 1.545s
 Ran 5 tests in 1.573s

 with patch
 Ran 5 tests in 0.807s
 Ran 5 tests in 0.880s
 Ran 5 tests in 0.812s


 mysql
 current behaviour
 Ran 5 tests in 17.101s
 Ran 5 tests in 15.396s
 Ran 5 tests in 15.487s

 with patch
 Ran 5 tests in 3.891s
 Ran 5 tests in 3.545s
 Ran 5 tests in 3.522s


 sqlite - 400 tables
 current behaviour
 Ran 5 tests in 2.006s
 Ran 5 tests in 2.039s
 Ran 5 tests in 2.055s

 with patch
 Ran 5 tests in 0.106s
 Ran 5 tests in 0.104s
 Ran 5 tests in 0.107s

 sqlite - 1000 tables
 django.db.utils.OperationalError: too many terms in compound SELECT

-- 
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.08c951873e8adf9745a1043a084224ac%40djangoproject.com.

Re: [Django] #31288: New ReplaceAuthMiddleware feature. (was: New ReplaceAuthMiddleware feature)

[Django]

#31288: New ReplaceAuthMiddleware feature.
-+-
 Reporter:  Théo Huchard |Owner:  Théo
 |  Huchard
 Type:  New feature  |   Status:  closed
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  django contrib auth  | Triage Stage:
  middleware ReplaceAuthMiddleware   |  Unreviewed
  3.0 ease of use for big projects   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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


Comment:

 Thanks for this ticket, however I don't think that keeping in settings the
 list of URLs which require to be logged is something that we would like to
 add to Django. We've already provided multiple ways to achieve 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.4a5d719c89bfa8c96f3819944d7d518f%40djangoproject.com.

Re: [Django] #31286: Database specific fields checks should be databases aware.

[Django]

#31286: Database specific fields checks should be databases aware.
-+-
 Reporter:  Hongtao Ma   |Owner:  Hongtao
 |  Ma
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Hongtao Ma):

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


Comment:

 [https://github.com/django/django/pull/12472 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/063.6c6aeae7ab16fc7072c13dae75e5c556%40djangoproject.com.

Re: [Django] #30040: Use a default permission name in docs examples to avoid confusion

[Django]

#30040: Use a default permission name in docs examples to avoid confusion
-+-
 Reporter:  Adrian Samatan   |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  template | Triage Stage:  Ready for
  permissions documentation  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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

Re: [Django] #31288: New ReplaceAuthMiddleware feature

[Django]

#31288: New ReplaceAuthMiddleware feature
-+-
 Reporter:  Théo Huchard |Owner:  Théo
 |  Huchard
 Type:  New feature  |   Status:  assigned
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  django contrib auth  | Triage Stage:
  middleware ReplaceAuthMiddleware   |  Unreviewed
  3.0 ease of use for big projects   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Théo Huchard):

 * version:  3.0 => 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/064.36b758c26d9c603e74a25f11447e90ed%40djangoproject.com.

Re: [Django] #31288: New ReplaceAuthMiddleware feature

[Django]

#31288: New ReplaceAuthMiddleware feature
-+-
 Reporter:  Théo Huchard |Owner:  Théo
 |  Huchard
 Type:  New feature  |   Status:  assigned
Component:  contrib.auth |  Version:  3.0
 Severity:  Normal   |   Resolution:
 Keywords:  django contrib auth  | Triage Stage:
  middleware ReplaceAuthMiddleware   |  Unreviewed
  3.0 ease of use for big projects   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Théo Huchard):

 * owner:  nobody => Théo Huchard
 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.d450c02adb2519004bd028e19c078446%40djangoproject.com.

Re: [Django] #31286: Database specific fields checks should be databases aware.

[Django]

#31286: Database specific fields checks should be databases aware.
-+-
 Reporter:  Hongtao Ma   |Owner:  Hongtao
 |  Ma
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by felixxm):

 You have to pass `databases={'default', 'other'}` to `model.check()` calls
 in `TestMultiDBChecks`.

-- 
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.b4d692681e6f9e390e4d42fb187d18f0%40djangoproject.com.

Re: [Django] #31288: New ReplaceAuthMiddleware feature

[Django]

#31288: New ReplaceAuthMiddleware feature
-+-
 Reporter:  TheoHd   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.auth |  Version:  3.0
 Severity:  Normal   |   Resolution:
 Keywords:  django contrib auth  | Triage Stage:
  middleware ReplaceAuthMiddleware   |  Unreviewed
  3.0 ease of use for big projects   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by TheoHd):

 * Attachment "middleware.py" added.

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

[Django] #31288: New ReplaceAuthMiddleware feature

[Django]

#31288: New ReplaceAuthMiddleware feature
-+-
   Reporter:  TheoHd |  Owner:  nobody
   Type:  New| Status:  new
  feature|
  Component: |Version:  3.0
  contrib.auth   |   Keywords:  django contrib auth
   Severity:  Normal |  middleware ReplaceAuthMiddleware
   Triage Stage: |  3.0 ease of use for big projects
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hello,

 I have developped a new feature as a middleware that I am using for a
 personal project. I think it could be a great implementation for Django.

 Here is an example of usage in the {{{settings.py}}} file:

 {{{
 #!div style="font-size: 100%"
 Code highlighting:
   {{{#!python
 REPLACE_URL_IF_UNLOGGED = {
 "replace": ["index", "logout"],
 "by": "/login"
 }
 REPLACE_URL_IF_LOGGED = {
 "replace": ["login"],
 "by": "/"
 }
   }}}
 }}}

 The goal here is to redirect the user if he is logged or unlogged directly
 from the replace URL.

 In my example, if the user is unlogged and trying to access the URL that
 was defined in {{{urls.py}}} like below:

 {{{
 #!div style="font-size: 100%"
 Code highlighting:
   {{{#!python
 urlpatterns = [
 path('', index, name="index"),
 path('login', login.view, name='login'),
 path('logout', logout.execute, name='logout')
 ]
   }}}
 }}}

 ...he will automatically be redirected to the {{{"by"}}} element, just by
 checking if the user is logged or not.

 So in this example, if the user is actually logged in and tries to access
 the {{{login}}} URL defined in {{{urls.py}}} he'll be redirected to the
 {{{index}}} URL.
 And if the user is unlogged and try to access the {{{index}}} or
 {{{logout}}} URL, he'll be redirected to the {{{login}}} URL.

 I thing that it might be a nice addition to the example in the doc:


 {{{
 #!div style="font-size: 100%"
 Code highlighting:
   {{{#!python
 from django.contrib.auth.decorators import login_required

 @login_required
 def my_view(request):
 ...
   }}}
 }}}

 ...since it can ease URL redirection directly from the {{{settings.py}}}
 file instead of using decorator.

-- 
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/049.9611f498b772da9a54b8db73a0b3a585%40djangoproject.com.

Re: [Django] #31286: Database specific fields checks should be databases aware.

[Django]

#31286: Database specific fields checks should be databases aware.
-+-
 Reporter:  Hongtao Ma   |Owner:  Hongtao
 |  Ma
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Hongtao Ma):

 * owner:  nobody => Hongtao Ma
 * status:  new => assigned


Comment:

 Applied the patch, two testcases failed, however:

 * FAIL: test_checks_called_on_the_default_database
 (check_framework.test_multi_db.TestMultiDBChecks)
 * FAIL: test_checks_called_on_the_other_database
 (check_framework.test_multi_db.TestMultiDBChecks)

 {{{
 for alias in databases:
 if router.allow_migrate(alias, app_label,
 model_name=self.model._meta.model_name):
 return connections[alias].validation.check_field(self,
 **kwargs)
 return []
 }}}
 The early return will cause only a single backend be checked, in case of
 multiple backends provided:
 {{{
 (djangodev) ➜  my_test_proj git:(iss_check) ✗ python manage.py check
 --database sqlite3 --database mysql
 System check identified no issues (0 silenced).
 (djangodev) ➜  my_test_proj git:(iss_check) ✗ python manage.py check
 --database mysql
 SystemCheckError: System check identified some issues:

 ERRORS:
 issue.AnotherIndex.name: (mysql.E001) MySQL does not allow unique
 CharFields to have a max_length > 255.
 issue.Networkservergroup.groupname: (mysql.E001) MySQL does not allow
 unique CharFields to have a max_length > 255.

 System check identified 2 issues (0 silenced).
 (djangodev) ➜  my_test_proj git:(iss_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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.52158b16cde1c4d5a6bbe187b115d654%40djangoproject.com.

Re: [Django] #28699: REMOTE_USER issues with CSRF

[Django]

#28699: REMOTE_USER issues with CSRF
--+
 Reporter:  stephanm  |Owner:  Rodrigo
 Type:  Bug   |   Status:  assigned
Component:  contrib.auth  |  Version:  1.11
 Severity:  Normal|   Resolution:
 Keywords:  remote user   | 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):

 * needs_tests:  0 => 1


Comment:

 [https://github.com/django/django/pull/12402 New PR] that suggests using
 `CsrfViewMiddleware._get_token()` in `process_view()`. (This was how the
 token was fetched prior to c4c128d67c7dc2830631c6859a204c9d259f1fb1.) If
 there's no issue with that, then it looks feasible.

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

Re: [Django] #31185: fields.E310-E311 should take into account UniqueConstraints without conditions.

[Django]

#31185: fields.E310-E311 should take into account UniqueConstraints without
conditions.
-+-
 Reporter:  Pavel Garkin |Owner:  Ahmad
 |  Abdallah
 Type:  Bug  |   Status:  assigned
Component:  Core (System |  Version:  master
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:  UniqueConstraint | Triage Stage:  Accepted
  unique_together E310 E311  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Ahmad Abdallah):

 Posting a patch soon

-- 
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.db6bd46956b004b19257272281aadbb9%40djangoproject.com.

Re: [Django] #31286: Database specific fields checks should be databases aware. (was: Database specific checks always goes to the 'default' backend)

[Django]

#31286: Database specific fields checks should be databases aware.
-+-
 Reporter:  Hongtao Ma   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by felixxm):

 * cc: Simon Charette (added)
 * easy:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 Thanks, this was missed in 0b83c8cc4db95812f1e15ca19d78614e94cf38dd. We
 should use here the same approach and pass `databases` to these checks:
 {{{
 diff --git a/django/db/models/fields/__init__.py
 b/django/db/models/fields/__init__.py
 index 6bd95f542c..c54b8f6e31 100644
 --- a/django/db/models/fields/__init__.py
 +++ b/django/db/models/fields/__init__.py
 @@ -335,11 +335,13 @@ class Field(RegisterLookupMixin):
  else:
  return []

 -def _check_backend_specific_checks(self, **kwargs):
 +def _check_backend_specific_checks(self, databases=None, **kwargs):
  app_label = self.model._meta.app_label
 -for db in connections:
 -if router.allow_migrate(db, app_label,
 model_name=self.model._meta.model_name):
 -return connections[db].validation.check_field(self,
 **kwargs)
 +if databases is None:
 +return []
 +for alias in databases:
 +if router.allow_migrate(alias, app_label,
 model_name=self.model._meta.model_name):
 +return connections[alias].validation.check_field(self,
 **kwargs)
  return []

  def _check_validators(self):
 }}}

-- 
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.e5868ed0a9ba75b795285b35c5a2a204%40djangoproject.com.

Re: [Django] #31185: fields.E310-E311 should take into account UniqueConstraints without conditions.

[Django]

#31185: fields.E310-E311 should take into account UniqueConstraints without
conditions.
-+-
 Reporter:  Pavel Garkin |Owner:  Ahmad
 |  Abdallah
 Type:  Bug  |   Status:  assigned
Component:  Core (System |  Version:  master
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:  UniqueConstraint | Triage Stage:  Accepted
  unique_together E310 E311  |
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


-- 
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.cda15b915665a43a543d24b45e50a955%40djangoproject.com.

Re: [Django] #31187: Detection of existing total ordering in admin changelist should take into account UniqueConstraints without conditions.

[Django]

#31187: Detection of existing total ordering in admin changelist should take 
into
account UniqueConstraints without conditions.
-+-
 Reporter:  Fabio Sangiovanni|Owner:  Fabio
 |  Sangiovanni
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"b457068cf272bc9912187a2b74445110735e" b457068c]:
 {{{
 #!CommitTicketReference repository=""
 revision="b457068cf272bc9912187a2b74445110735e"
 Fixed #31187 -- Fixed detecting of existing total ordering in admin
 changelist when using Meta.constraints.

 Detection of existing total ordering in admin changelist now takes into
 account non-partial unique constraints.
 }}}

-- 
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.cba347f90b04614568795d03d151ce0b%40djangoproject.com.

Re: [Django] #31187: Detection of existing total ordering in admin changelist should take into account UniqueConstraints without conditions.

[Django]

#31187: Detection of existing total ordering in admin changelist should take 
into
account UniqueConstraints without conditions.
-+-
 Reporter:  Fabio Sangiovanni|Owner:  Fabio
 |  Sangiovanni
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"d270c10a723ca04e467e08d6d8b38ae392191f2d" d270c10a]:
 {{{
 #!CommitTicketReference repository=""
 revision="d270c10a723ca04e467e08d6d8b38ae392191f2d"
 Refs #31187 -- Added total_unique_constraints property to model's Options.
 }}}

-- 
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.41a4632929bbbf1a50c0d1786963de67%40djangoproject.com.

[Django] #31287: Rename mark_safe and "safe" template filters to something less safe sounding

[Django]

#31287: Rename mark_safe and "safe" template filters to something less safe
sounding
-+
   Reporter:  Adam (Chainz) Johnson  |  Owner:  nobody
   Type:  Cleanup/optimization   | Status:  new
  Component:  Template system|Version:  master
   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  |
-+
 As discussed on django-developers in Jan 2018:
 https://groups.google.com/forum/#!msg/django-developers/AvgxWR-0VrE
 /b8a3g8q-AwAJ . And occasionally brought up again in other community
 forums, many developers reporting overuse of `mark_safe()` in real world
 projects.

 Copying Stuart Cox's first post from the mailing list thread:

 > In my experience, misuse of `mark_safe()` — i.e. marking stuff safe
 which isn’t actually safe (e.g. HTML from a rich text input) — is one of
 the biggest causes of XSS vulnerabilities in Django projects.
 >
 > The docs warn to be careful, but unfortunately I think Django devs have
 just got too used to `mark_safe()` being the way to insert HTML in a
 template. And it’s easy for something that was safe when it was authored
 (e.g. calling mark_safe() on a hard-coded string) to be copied /
 repurposed / adapted into a case which is no longer be safe (e.g. that
 string replaced with a user-provided value).
 >
 > Some other frameworks use scary sounding names to help reinforce that
 there are dangers around similar features, and that this isn’t something
 you should use in everyday work — e.g. React’s dangerouslySetInnerHTML.
 >
 > Relatedly, this topic suggested making it more explicit that mark_safe()
 refers to being safe for use in HTML contexts (rather than JS, CSS, SQL,
 etc).
 >
 > Combining the two, it would be great if Django could rename mark_safe()
 to dangerously_trust_html(), |safe to |dangerously_trust_html,
 @csrf_exempt to @dangerously_csrf_exempt, etc.
 >
 > Developers who know what they’re doing with these could then be
 encouraged to create suitable wrappers which handle their use case safely
 internally — e.g.:
 >
 > {{{
 > @register.filter
 > def sanitize_and_trust_html(value):
 > # Safe because we sanitize before trusting
 >return dangerously_trust_html(bleach.clean(value))
 > }}}

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

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

[Django] #31286: Database specific checks always goes to the 'default' backend

[Django]

#31286: Database specific checks always goes to the 'default' backend
-+-
   Reporter:  Hongtao|  Owner:  nobody
  Ma |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 In an attempt to trigger the check Error mentioned in Tickets: #31144, I
 found that the check for database backend doesn't check against the
 backend specified, e.g. --database mysql, rather, it always checks against
 the 'default' backend.

 After diving into the source code, I found the following method defined in
 django/db/models/fields/__init__.py
 {{{
 def _check_backend_specific_checks(self, **kwargs):
 app_label = self.model._meta.app_label
 for db in connections:
 if router.allow_migrate(db, app_label,
 model_name=self.model._meta.model_name):
 return connections[db].validation.check_field(self,
 **kwargs)
 return []
 }}}
 It checks the first db defined in connections rather those provided by
 users.

 A proposed change would be:
 {{{
 def _check_backend_specific_checks(self, **kwargs):
 app_label = self.model._meta.app_label
 errors = []
 for db in kwargs['databases'] or ['default']:
 if router.allow_migrate(db, app_label,
 model_name=self.model._meta.model_name):
 errors.extend(connections[db].validation.check_field(self,
 **kwargs))
 return errors
 }}}

 It worked as intended on my local machine.
 I would happily provide a patch for this one.

-- 
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.dba89b3e04cfa65489de039778881fb3%40djangoproject.com.