Re: [Django] #33277: SimpleTestCase does not block database connections in threads

2021-12-08 Thread Django 
#33277: SimpleTestCase does not block database connections in threads
---+---
 Reporter:  Daniel Hahler  |Owner:  wangxiaolei
 Type:  New feature|   Status:  assigned
Component:  Testing framework  |  Version:  3.2
 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 wangxiaolei):

 * owner:  nobody => wangxiaolei
 * 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.d044c921484bfc8dad4d14ae7807b229%40djangoproject.com.

Re: [Django] #33340: DatabaseCache backend doesn't quote all fields in queries

2021-12-08 Thread Django 
#33340: DatabaseCache backend doesn't quote all fields in queries
-+-
 Reporter:  Tim Graham   |Owner:  Arsalan
 |  Ghassemi
 Type:  Bug  |   Status:  assigned
Component:  Core (Cache system)  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * 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/067.48d61301aa1695c982f9dae23439186e%40djangoproject.com.

Re: [Django] #32338: Accessibility issues with Django forms RadioSelect and CheckboxSelectMultiple

2021-12-08 Thread Django 
#32338: Accessibility issues with Django forms RadioSelect and
CheckboxSelectMultiple
-+-
 Reporter:  Thibaud Colas|Owner:  David
 |  Smith
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility,   | Triage Stage:  Ready for
  forms, wcag|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  1 => 0
 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #33338: Document that @never_cache and add_never_cache_headers() set the Expires header.

2021-12-08 Thread Django 
#8: Document that @never_cache and add_never_cache_headers() set the Expires
header.
-+-
 Reporter:  Andy Chosak  |Owner:  Marcelo
 Type:   |  Galigniana
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Cache system)  |  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  cache| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Marcelo Galigniana):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/15167 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/064.4a119725d4bf31b1cad475883b33ea89%40djangoproject.com.

Re: [Django] #31842: django.core.signing.dumps() and loads() not backwards compatible

2021-12-08 Thread Django 
#31842: django.core.signing.dumps() and loads() not backwards compatible
-+-
 Reporter:  Markus Holtermann|Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  3.1
 Severity:  Release blocker  |   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
-+-

Comment (by Riley Chase):

 Was there a reason the `DEFAULT_HASHING_ALGORITHM` solution was used in
 preference to adding the `algorithm` parameter to the two methods?

 The project I'm working on needs to be able to select the hashing
 algorithm so we can progressively upgrade several systems that all use
 these methods. Updating them all at once is not feasible and we have a
 requirement to maintain compatibility for a short period while the upgrade
 is happening. Exposing the `algorithm` parameter would allow us to do this
 easily and provide the same functionality if the default algorithm changes
 again in the future.

 Exposing the `algorithm` parameter would also allow users to opt into more
 secure hashing algorithms ahead of Django making it the default.

 If possible, I'd like to see this reopened (or another ticket if that's
 the preference) so we can add the `algorithm` parameter to these methods.
 I'd also be willing to put a PR together, I've not contributed to Django
 before but this seems straight forward enough.

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

Re: [Django] #33340: DatabaseCache backend doesn't quote all fields in queries

2021-12-08 Thread Django 
#33340: DatabaseCache backend doesn't quote all fields in queries
-+-
 Reporter:  Tim Graham   |Owner:  Arsalan
 |  Ghassemi
 Type:  Bug  |   Status:  assigned
Component:  Core (Cache system)  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Arsalan Ghassemi):

 * has_patch:  0 => 1


Comment:

 Hi,

 I opened a PR for this issue : https://github.com/django/django/pull/15166

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

Re: [Django] #33319: Query.change_aliases raises an AssertionError

2021-12-08 Thread Django 
#33319: Query.change_aliases raises an AssertionError
-+-
 Reporter:  Ömer Faruk Abacı |Owner:  Ömer
 |  Faruk Abacı
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"bb8435f5db6ed5caa33346387e925c8287f2c683" bb8435f]:
 {{{
 #!CommitTicketReference repository=""
 revision="bb8435f5db6ed5caa33346387e925c8287f2c683"
 [4.0.x] Refs #33319 -- Added note about commutation of QuerySet's |
 operator.

 Backport of f04b44bad40369ec2df74b16adb4d3f09350e4b2 from main
 }}}

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

Re: [Django] #33319: Query.change_aliases raises an AssertionError

2021-12-08 Thread Django 
#33319: Query.change_aliases raises an AssertionError
-+-
 Reporter:  Ömer Faruk Abacı |Owner:  Ömer
 |  Faruk Abacı
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"f04b44bad40369ec2df74b16adb4d3f09350e4b2" f04b44ba]:
 {{{
 #!CommitTicketReference repository=""
 revision="f04b44bad40369ec2df74b16adb4d3f09350e4b2"
 Refs #33319 -- Added note about commutation of QuerySet's | operator.
 }}}

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

Re: [Django] #33319: Query.change_aliases raises an AssertionError

2021-12-08 Thread Django 
#33319: Query.change_aliases raises an AssertionError
-+-
 Reporter:  Ömer Faruk Abacı |Owner:  Ömer
 |  Faruk Abacı
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"81739a45b5ae8f534910aaabc7e9b457eaa34163" 81739a4]:
 {{{
 #!CommitTicketReference repository=""
 revision="81739a45b5ae8f534910aaabc7e9b457eaa34163"
 Fixed #33319 -- Fixed crash when combining with the | operator querysets
 with aliases that conflict.
 }}}

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

Re: [Django] #33319: Query.change_aliases raises an AssertionError

2021-12-08 Thread Django 
#33319: Query.change_aliases raises an AssertionError
-+-
 Reporter:  Ömer Faruk Abacı |Owner:  Ömer
 |  Faruk Abacı
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"f1bfdff6907e093ea6ce12e775f93add349adde7" f1bfdff6]:
 {{{
 #!CommitTicketReference repository=""
 revision="f1bfdff6907e093ea6ce12e775f93add349adde7"
 Refs #33319 -- Added comment about keys/values assertion in
 Query.change_aliases().
 }}}

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

Re: [Django] #33346: assertFormsetError() crashes on formset named "form".

2021-12-08 Thread Django 
#33346: assertFormsetError() crashes on formset named "form".
-+-
 Reporter:  OutOfFocus4  |Owner:  Baptiste
 |  Mispelon
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  4.0
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"15031852c5ef6b3713bb9766d918460ea46e254e" 15031852]:
 {{{
 #!CommitTicketReference repository=""
 revision="15031852c5ef6b3713bb9766d918460ea46e254e"
 [4.0.x] Fixed #33346 -- Fixed SimpleTestCase.assertFormsetError() crash on
 a formset named "form".

 Thanks OutOfFocus4 for the report.

 Regression in 456466d932830b096d39806e291fe23ec5ed38d5.

 Backport of cb383753c0e0eb52306e1024d32a782549c27e61 from main.
 }}}

-- 
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/069.8a2a3d7b9f9f7dba39aeaa8d010f09eb%40djangoproject.com.

Re: [Django] #33346: assertFormsetError() crashes on formset named "form".

2021-12-08 Thread Django 
#33346: assertFormsetError() crashes on formset named "form".
-+-
 Reporter:  OutOfFocus4  |Owner:  Baptiste
 |  Mispelon
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  4.0
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"cb383753c0e0eb52306e1024d32a782549c27e61" cb383753]:
 {{{
 #!CommitTicketReference repository=""
 revision="cb383753c0e0eb52306e1024d32a782549c27e61"
 Fixed #33346 -- Fixed SimpleTestCase.assertFormsetError() crash on a
 formset named "form".

 Thanks OutOfFocus4 for the report.

 Regression in 456466d932830b096d39806e291fe23ec5ed38d5.
 }}}

-- 
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/069.202f16fa5f179d4b50eb1e141ecda567%40djangoproject.com.

Re: [Django] #33348: Change API of assertFormError to take an actual form object

2021-12-08 Thread Django 
#33348: Change API of assertFormError to take an actual form object
--+
 Reporter:  Baptiste Mispelon |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Testing framework |  Version:  dev
 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 Mariusz Felisiak):

 * stage:  Unreviewed => Accepted


Comment:

 Agreed, let's change the first argument to `form`/`formset` and deprecate
 passing a `response` in it.

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

Re: [Django] #33346: assertFormsetError() crashes on formset named "form".

2021-12-08 Thread Django 
#33346: assertFormsetError() crashes on formset named "form".
-+-
 Reporter:  OutOfFocus4  |Owner:  Baptiste
 |  Mispelon
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  4.0
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * 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/069.42f576ff88b6be6896087e683233ef0d%40djangoproject.com.

[Django] #33349: Add option to produce duration_string without days

2021-12-08 Thread Django 
#33349: Add option to produce duration_string without days
+
   Reporter:  Claude Paroz  |  Owner:  nobody
   Type:  New feature   | Status:  new
  Component:  Forms |Version:  dev
   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 a form with a custom field (inheriting from Django's DurationField)
 allowing to input duration in the form "hh:mm".

 However, when user inputs durations > "23:59", re-displaying those
 durations is kind of broken ("1 ..."). Customizing `prepare_value` is
 rather straightforward, however I'd like to avoid rewriting the whole
 `django.utils.duration.duration_string`. If that function would accept a
 `use_days` argument, it would be a lot easier to achieve my use case.

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

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

Re: [Django] #33347: django.contrib.gis.geos.MultiPolygon segfault on arm

2021-12-08 Thread Django 
#33347: django.contrib.gis.geos.MultiPolygon segfault on arm
---+--
 Reporter:  Horeb Parraud  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  GIS|  Version:  4.0
 Severity:  Normal |   Resolution:  duplicate
 Keywords:  geos multipolygon  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Mariusz Felisiak):

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


Comment:

 Currently we cannot prove that Django is at fault. Duplicate of #32600.

-- 
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/070.fc4413a7a4258cc85839ff23af296ff2%40djangoproject.com.

Re: [Django] #33348: Change API of assertFormError to take an actual form object

2021-12-08 Thread Django 
#33348: Change API of assertFormError to take an actual form object
-+-
 Reporter:  Baptiste Mispelon|Owner:  nobody
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Testing framework|  Version:  dev
 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 Baptiste Mispelon):

 As an argument in favor of this change, may I present this lines from
 `tests/admin_views/tests.py:6540` [1]

 {{{#!py
 msg = "The formset 'inline_admin_formset' in context 22 does not contain
 any non-form errors."
 with self.assertRaisesMessage(AssertionError, msg):
 self.assertFormsetError(response, 'inline_admin_formset', None, None,
 ['Error'])
 }}}

 Over the years as more and more templates got involved in the rendering of
 admin views, the exact number needed to make this test pass went from 4 to
 10 to 12 to 22 (and every time, I suspect someone changed it manually to
 whichever new number the test failure asked for).

 With the change I propose, the test would look like this:
 {{{#!py
 for formset in response.context['inline_admin_formsets']:
 with self.assertRaisesMessage("The formset does not contain any non-
 form errors"):
 self.assertFormsetError(formset, None, None, ['error']
 }}}

 Though on second thought, in this case I think we can skip
 `assertFormsetError` altogether:
 {{{#!py
 for i, formset in enumerate(response.context['inline_admin_formsets']):
 with self.subTest(i=i):
 self.assertEqual(formset.non_form_errors(), [])
 }}}

 [1]
 
https://github.com/django/django/blob/8a4e5067605e608c3fcbb5ca11e0019eac8b40aa/tests/admin_views/tests.py#L6540

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

Re: [Django] #19721: Django admin allows filtering using the field lookups such as "in", but it is impossible to include a value that contains a comma

2021-12-08 Thread Django 
#19721: Django admin allows filtering using the field lookups such as "in", but 
it
is impossible to include a value that contains a comma
-+-
 Reporter:  aruseni  |Owner:  Shreya
 |  Bamne
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  1.4
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson ):

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


Comment:

 In [changeset:"8a4e5067605e608c3fcbb5ca11e0019eac8b40aa" 8a4e5067]:
 {{{
 #!CommitTicketReference repository=""
 revision="8a4e5067605e608c3fcbb5ca11e0019eac8b40aa"
 Fixed #19721 -- Allowed admin filters to customize the list separator.
 }}}

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

Re: [Django] #19721: Django admin allows filtering using the field lookups such as "in", but it is impossible to include a value that contains a comma

2021-12-08 Thread Django 
#19721: Django admin allows filtering using the field lookups such as "in", but 
it
is impossible to include a value that contains a comma
-+-
 Reporter:  aruseni  |Owner:  Shreya
 |  Bamne
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson ):

 In [changeset:"2b76f457494414f96d3848a5591909cbb48239e9" 2b76f457]:
 {{{
 #!CommitTicketReference repository=""
 revision="2b76f457494414f96d3848a5591909cbb48239e9"
 Refs #19721 -- Corrected list formatting in admin filters docs.
 }}}

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

[Django] #33348: Change API of assertFormError to take an actual form object

2021-12-08 Thread Django 
#33348: Change API of assertFormError to take an actual form object
+--
   Reporter:  Baptiste Mispelon |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  assigned
  Component:  Testing framework |Version:  dev
   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 |
+--
 The current signature of `assertFormError` is `(response, form, field,
 errors, msg_prefix='')` where:

 - `response` is a response object (specifically one generated by the test
 client because it needs `response.context`)
 - `form` is the name of a form (string) to be found in the response's
 context
 - `field` is a name of a field in the form (string)
 - `errors` is either a list of error strings, a single error string
 (equivalent to `[error]`) or `None` (equivalent to `[]`)
 - `msg_prefix` is a string added to the test failure message


 Personally I've always found this `response`/`form` API to be clunky since
 I often want to test a form directly without having to go through the test
 client.
 It would be a lot easier to use if we could pass a form object directly. I
 don't really understand why the API was implemented like this to begin
 with.

 On top of that, now that Django uses template-based rendering for forms,
 formsets and widgets there are a lot of contexts to search in
 `response.context` and a lot of possibilities for clashing names (see
 #33346).

 I would therefore propose the following new signature:
 `assertFormError(form, field, errors, msg_prefix='')` with `form` being an
 actual `Form` object and all other parameters staying the same.
 The deprecation should be straightforward to implement by checking if
 `form` is a response object (`isinstance` check) or if `response` kwarg
 has been passed.


 With that change `assertFormsetError` becomes mostly useless since one can
 simply do `assertFormError(formset.forms[i], field_name, errors)`. The one
 usecase that wouldn't be covered is `i = None + field_name=None` which
 checks the `errors` list against the formset's `non_form_errors()`.
 We could either leave `assertFormsetError` in place as a convenience
 method (with a similar change to its API to accept a formset object
 directly) or deprecate more agressively by suggesting the user tests the
 output of `formset.non_field_errors()` directly.

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

Re: [Django] #33338: Document that @never_cache and add_never_cache_headers() set the Expires header.

2021-12-08 Thread Django 
#8: Document that @never_cache and add_never_cache_headers() set the Expires
header.
-+-
 Reporter:  Andy Chosak  |Owner:  Marcelo
 Type:   |  Galigniana
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Cache system)  |  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  cache| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Marcelo Galigniana):

 * owner:  nobody => Marcelo Galigniana
 * 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.e7ed87c5749c2750b76f0145722f52ab%40djangoproject.com.

Re: [Django] #19721: Django admin allows filtering using the field lookups such as "in", but it is impossible to include a value that contains a comma

2021-12-08 Thread Django 
#19721: Django admin allows filtering using the field lookups such as "in", but 
it
is impossible to include a value that contains a comma
-+-
 Reporter:  aruseni  |Owner:  Shreya
 |  Bamne
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * needs_better_patch:  1 => 0
 * stage:  Accepted => Ready for checkin
 * needs_docs:  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.d2c60506baf8d8d8822d87df075fa104%40djangoproject.com.

[Django] #33347: django.contrib.gis.geos.MultiPolygon segfault on arm

2021-12-08 Thread Django 
#33347: django.contrib.gis.geos.MultiPolygon segfault on arm
-+-
   Reporter: |  Owner:  nobody
  HorebParraud   |
   Type:  Bug| Status:  new
  Component:  GIS|Version:  4.0
   Severity:  Normal |   Keywords:  geos multipolygon
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hello,

 I am a python django developer and since yesterday (with the release of
 Django4) I try to launch my project on a mac m1

 Unfortunately, python crashes systematically when I use MultiPolygons
 (very present in the project)


 {{{
 versioning:
 - Python 3.9
 - Django 4.0
 - djangorestframework-gis 0.17
 - GDAL 3.3.1
 - geos 3.10
 }}}


 {{{
 shell trace:
 $/> python manage.py shell
 Python 3.9.9 (main, Nov 21 2021, 03:16:13)
 Type 'copyright', 'credits' or 'license' for more information
 IPython 7.30.1 -- An enhanced Interactive Python. Type '?' for help.

 In [1]: from django.contrib.gis.geos import MultiPolygon

 In [2]: p = MultiPolygon()
 [1]58500 bus error  python manage.py shell
 }}}


 {{{
 Python traces:
 VM Region Info: 0x16d754000 is in 0x16d754000-0x16d758000;  bytes after
 start: 0  bytes before end: 16383
   REGION TYPESTART - END [ VSIZE] PRT/MAX
 SHRMOD  REGION DETAIL
   Stack   16c754000-16d754000[ 16.0M] rw-/rwx
 SM=PRV  thread 0
 --->  STACK GUARD 16d754000-16d758000[   16K] ---/rwx
 SM=NUL  ... for thread 1
   Stack   16d758000-16e76[ 16.0M] rw-/rwx
 SM=PRV  thread 1

 Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
 0   libgeos_c.1.16.0.dylib 0x105c1d340
 GEOSGeom_createCollection_r + 88
 1   libgeos_c.1.16.0.dylib 0x105c1d330
 GEOSGeom_createCollection_r + 72
 2   libffi.dylib   0x1a5af0050 ffi_call_SYSV +
 80
 3   libffi.dylib   0x1a5af89e4 ffi_call_int +
 948
 }}}

-- 
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/055.b85f7a44ca7d86bbae954e26c17621c4%40djangoproject.com.

Re: [Django] #33346: assertFormsetError() crashes on formset named "form".

2021-12-08 Thread Django 
#33346: assertFormsetError() crashes on formset named "form".
-+-
 Reporter:  OutOfFocus4  |Owner:  Baptiste
 |  Mispelon
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  4.0
 Severity:  Release blocker  |   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 Baptiste Mispelon):

 * cc: Baptiste Mispelon (added)
 * has_patch:  0 => 1


Comment:

 PR here: https://github.com/django/django/pull/15165

 I went with the `isinstance` check wich seems a bit more robust since
 `forms` seems like quite a common attribute name and might catch other
 non-formset things.

-- 
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/069.b39fa8d6b64810385116f303d322c9cc%40djangoproject.com.

Re: [Django] #33346: assertFormsetError() crashes on formset named "form".

2021-12-08 Thread Django 
#33346: assertFormsetError() crashes on formset named "form".
-+-
 Reporter:  OutOfFocus4  |Owner:  Baptiste
 |  Mispelon
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  4.0
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Baptiste Mispelon):

 * owner:  nobody => Baptiste Mispelon
 * status:  new => assigned


Comment:

 Replying to [comment:4 Mariusz Felisiak]:
 > What do you think about skipping context values that are not a `FormSet`
 instance? or don't have the `forms` attribute. This should be backward
 compatible.

 I haven't thought it through completely, but my gut feeling is that your
 proposed fix would work for the reported regression but there might still
 be corner cases that could fail. But those corner cases might have already
 been broken so it's probably ok.

 I'll start working on a PR, it'll be easier for me to think it through
 with some concrete examples.

 Replying to [comment:4 Mariusz Felisiak]:
 > We cannot change or deprecate an existing and documented API as a part
 of patch which is intended for backport. This can be discussed separately.
 Personally, I like the idea.

 Agreed, I'll open a separate ticket.

-- 
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/069.d6b0a306ac8afed22ae66e8fbc7e4f7f%40djangoproject.com.

Re: [Django] #33346: assertFormsetError() crashes on formset named "form".

2021-12-08 Thread Django 
#33346: assertFormsetError() crashes on formset named "form".
---+
 Reporter:  OutOfFocus4|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  4.0
 Severity:  Release blocker|   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Mariusz Felisiak):

 Replying to [comment:3 Baptiste Mispelon]:
 > ...
 > Restricting the search to the first context would probably fix most
 issues like the one reported here, but it's not 100% correct (and
 backwards-incompatible).

 What do you think about skipping context values that are not a `FormSet`
 instance? or don't have the `forms` attribute. This should be backward
 compatible.

 >
 > The only way out that I could think of would be to deprecate passing a
 `response` to `assertFormError`/`assertFormsetError` in favor of passing
 the form/formset object directly. I think it would be a more natural API
 anway (I never understood why the assertions were based on the response to
 begin with).

 We cannot change or deprecate an existing and documented API as a part of
 patch which is intended for backport. This can be discussed separately.
 Personally, I like the idea.

-- 
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/069.332f4358e97628dd6e24a6e896b4ceb4%40djangoproject.com.

Re: [Django] #33346: assertFormsetError() crashes on formset named "form".

2021-12-08 Thread Django 
#33346: assertFormsetError() crashes on formset named "form".
---+
 Reporter:  OutOfFocus4|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  4.0
 Severity:  Release blocker|   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Baptiste Mispelon):

 I did some digging around `assertFormsetError` (and `assertFormError`)
 while working on #33301 and came to the conclusion that they might be
 fundamentally broken.

 Both methods work by looking for a specific name in the context of
 **each** template rendered during the execution of the view. When the name
 is not found in the template, it is skipped. If the name is found then the
 `context[name]` object is checked for the assertion.

 The issue is that you cannot always control which templates are rendered
 during your views, and especially what names those templates are using in
 their respective contexts.
 The situation is even worse now that Django uses templates to render
 forms, formsets and widgets.

 Restricting the search to the first context would probably fix most issues
 like the one reported here, but it's not 100% correct (and backwards-
 incompatible).

 The only way out that I could think of would be to deprecate passing a
 `response` to `assertFormError`/`assertFormsetError` in favor of passing
 the form/formset object directly. I think it would be a more natural API
 anway (I never understood why the assertions were based on the response to
 begin with).

-- 
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/069.06ea65e0b8e52d2e353d72d115762c06%40djangoproject.com.

Re: [Django] #33319: Query.change_aliases raises an AssertionError

2021-12-08 Thread Django 
#33319: Query.change_aliases raises an AssertionError
-+-
 Reporter:  Ömer Faruk Abacı |Owner:  Ömer
 |  Faruk Abacı
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  1 => 0
 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #33331: Improve exception handling with `cursor.close()` after errors

2021-12-08 Thread Django 
#1: Improve exception handling with `cursor.close()` after errors
-+-
 Reporter:  Daniel Hahler|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 Hi Daniel. Thanks for the reply.

 It's OK to not read the thread :)

 > ...not about context or cause, but only using raise from properly
 (according to...

 It's the force of ''properly'' here that's in doubt.

 On investigation, the difference between the two syntaxes amounted to no
 more (not much more) that the text used between the tracebacks — which are
 chained either way, either ''implicitly'' or ''explicitly'', unless `from
 None` is used. That difference in text, ''"During handling of the above
 exception, another exception occurred"'' vs ''"The above exception was the
 direct cause of the following exception"'', wasn't felt significant — not
 compared to the more verbose syntax, and in the PR you have here, much
 more verbose block in order to decide when to use it.

 Thus, with the exceptions noted above, it was decided not to use the
 `from` syntax. (We didn't agree with the blog post that not using it was
 ''improper''.)

 So, if there's a concrete example, of ''"Look, you get this benefit"'',
 then I'm really happy to look at that, and learn a trick, but pending
 that, we have to go with the previous consensus. I hope that makes sense.
 Thanks!

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

Re: [Django] #32290: TemplateNotFound if relative path passed to {% include %} in variable

2021-12-08 Thread Django 
#32290: TemplateNotFound if relative path passed to {% include %} in variable
-+-
 Reporter:  Peter Inglesby   |Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  3.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"7d02fa94332b43c7527c1b816787b4c560cf6bf6" 7d02fa94]:
 {{{
 #!CommitTicketReference repository=""
 revision="7d02fa94332b43c7527c1b816787b4c560cf6bf6"
 Refs #32290 -- Optimized construct_relative_path() by delay computing
 has_quotes.
 }}}

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