Re: [Django] #31538: models.E015 is raised when ordering uses lookups that are not transforms.

[Django]

#31538: models.E015 is raised when ordering uses lookups that are not 
transforms.
--+
 Reporter:  Simon Meers   |Owner:  felixxm
 Type:  Bug   |   Status:  assigned
Component:  Core (System checks)  |  Version:  3.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 felixxm):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/12858 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/065.1e3786153f652be8955a57cd8b675753%40djangoproject.com.

Re: [Django] #31538: models.E015 is raised when ordering uses lookups that are not transforms. (was: Django 3.0 raises invalid models.E015 check error)

[Django]

#31538: models.E015 is raised when ordering uses lookups that are not 
transforms.
--+
 Reporter:  Simon Meers   |Owner:  felixxm
 Type:  Bug   |   Status:  assigned
Component:  Core (System checks)  |  Version:  3.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 felixxm):

 * status:  new => assigned
 * severity:  Normal => Release blocker
 * cc: Hasan Ramezani (added)
 * owner:  nobody => felixxm
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the report, it's related with using lookup that are not
 transforms, e.g. `isnull`
 {{{
 def test_ordering_pointing_to_lookup_not_transform(self):
 class Model(models.Model):
 test = models.CharField(max_length=100)

 class Meta:
 ordering = ('test__isnull',)

 self.assertEqual(Model.check(), [])
 }}}

 Regression in 440505cb2cadbe1a5b9fba246bcde6c04f51d07e.

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

[Django] #31538: Django 3.0 raises invalid models.E015 check error

[Django]

#31538: Django 3.0 raises invalid models.E015 check error
+
   Reporter:  Simon Meers   |  Owner:  nobody
   Type:  Bug   | 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:  0
  UI/UX:  0 |
+
 {{{
 ./manage.py check
 SystemCheckError: System check identified some issues:
 ERRORS:

 app.Stock: (models.E015) 'ordering' refers to the nonexistent field,
 related field, or lookup 'supply__product__parent__isnull'.

 }}}

 However this ordering works fine:
 {{{
 >>>
 
list(Stock.objects.order_by('supply__product__parent__isnull').values_list('pk',
 flat=True)[:5])
 [1292, 1293, 1300, 1295, 1294]
 >>>
 
list(Stock.objects.order_by('-supply__product__parent__isnull').values_list('pk',
 flat=True)[:5])
 [108, 109, 110, 23, 107]
 }}}

 I believe it was fine until #29408 was implemented.

 `Stock.supply` is a foreign key to `Supply`, `Supply.product` is a foreign
 key to `Product`, `Product.parent` is a `ForeignKey('self',
 models.CASCADE, null=True)`

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

Re: [Django] #31410: Add check for fields of UniqueConstraints and CheckConstraint.

[Django]

#31410: Add check for fields of UniqueConstraints and CheckConstraint.
-+-
 Reporter:  Marnanel Thurman |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 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 Hasan Ramezani):

 * owner:  Rafael Arellano => Hasan Ramezani
 * 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/066.0ac744e7e78511b8806687f236426bd0%40djangoproject.com.

Re: [Django] #31537: Optionally log server_time with timezone

[Django]

#31537: Optionally log server_time with timezone
---+--
 Reporter:  thenewguy  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  3.0
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Description changed by thenewguy:

Old description:

> It would be helpful if logging format included the timezone for the
> logged time.  When this information is parsed (for example log
> aggregation via logstash) the timezone data would be very helpful to
> create a consistent timestamp.
>
> For reference, https://docs.python.org/3/library/logging.html
> {{{
> Changed in version 3.3: Previously, the default format was hard-coded as
> in this example: 2010-09-06 22:38:15,292 where the part before the comma
> is handled by a strptime format string ('%Y-%m-%d %H:%M:%S'), and the
> part after the comma is a millisecond value. Because strptime does not
> have a format placeholder for milliseconds, the millisecond value is
> appended using another format string, '%s,%03d' — and both of these
> format strings have been hardcoded into this method. With the change,
> these strings are defined as class-level attributes which can be
> overridden at the instance level when desired. The names of the
> attributes are default_time_format (for the strptime format string) and
> default_msec_format (for appending the millisecond value).
> }}}
>
> Since the date time output is not created via one format operation it is
> more complicated than just adding %Z or %z to the format string.
>
> Happy to do the work.  Please provide feedback/direction.

New description:

 It would be helpful if logging format included the timezone for the logged
 time.  When this information is parsed (for example log aggregation via
 logstash) the timezone data would be very helpful to create a consistent
 timestamp.

 For reference, https://docs.python.org/3/library/logging.html
 {{{
 Changed in version 3.3: Previously, the default format was hard-coded as
 in this example: 2010-09-06 22:38:15,292 where the part before the comma
 is handled by a strptime format string ('%Y-%m-%d %H:%M:%S'), and the part
 after the comma is a millisecond value. Because strptime does not have a
 format placeholder for milliseconds, the millisecond value is appended
 using another format string, '%s,%03d' — and both of these format strings
 have been hardcoded into this method. With the change, these strings are
 defined as class-level attributes which can be overridden at the instance
 level when desired. The names of the attributes are default_time_format
 (for the strptime format string) and default_msec_format (for appending
 the millisecond value).
 }}}

 Since the date time output is not created via one format operation it is
 more complicated than just adding %Z or %z to the format string.

 Happy to do the work.  Please provide feedback/direction.

 It seems like the simplest way to do this would be to always log in UTC
 and add the "Z" for timezone.  But +-offset could also be used if
 localtime needs to be supported

--

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

Re: [Django] #31534: Deprecate django.conf.urls.url().

[Django]

#31534: Deprecate django.conf.urls.url().
-+-
 Reporter:  David Smith  |Owner:  David
 Type:   |  Smith
  Cleanup/optimization   |   Status:  assigned
Component:  Core (URLs)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by David Smith):

 * 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/066.f1c1176120f9d80c998a717835494bec%40djangoproject.com.

Re: [Django] #31537: Optionally log server_time with timezone (was: Optionally log server_time with timzone)

[Django]

#31537: Optionally log server_time with timezone
---+--
 Reporter:  thenewguy  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  3.0
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

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

Re: [Django] #31537: Optionally log server_time with timzone

[Django]

#31537: Optionally log server_time with timzone
---+--
 Reporter:  thenewguy  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  3.0
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Description changed by thenewguy:

Old description:

> It would be helpful if logging format included the timezone for the
> logged time.  When this information is parsed (for example logging
> aggregation using logstash and the elastic stack) the timezone data would
> be very helpful so the time is correct.
>
> For reference, https://docs.python.org/3/library/logging.html
> {{{
> Changed in version 3.3: Previously, the default format was hard-coded as
> in this example: 2010-09-06 22:38:15,292 where the part before the comma
> is handled by a strptime format string ('%Y-%m-%d %H:%M:%S'), and the
> part after the comma is a millisecond value. Because strptime does not
> have a format placeholder for milliseconds, the millisecond value is
> appended using another format string, '%s,%03d' — and both of these
> format strings have been hardcoded into this method. With the change,
> these strings are defined as class-level attributes which can be
> overridden at the instance level when desired. The names of the
> attributes are default_time_format (for the strptime format string) and
> default_msec_format (for appending the millisecond value).
> }}}
>
> Since the date time output is not created via one format operation it is
> more complicated than just adding %Z or %z to the format string

New description:

 It would be helpful if logging format included the timezone for the logged
 time.  When this information is parsed (for example log aggregation via
 logstash) the timezone data would be very helpful to create a consistent
 timestamp.

 For reference, https://docs.python.org/3/library/logging.html
 {{{
 Changed in version 3.3: Previously, the default format was hard-coded as
 in this example: 2010-09-06 22:38:15,292 where the part before the comma
 is handled by a strptime format string ('%Y-%m-%d %H:%M:%S'), and the part
 after the comma is a millisecond value. Because strptime does not have a
 format placeholder for milliseconds, the millisecond value is appended
 using another format string, '%s,%03d' — and both of these format strings
 have been hardcoded into this method. With the change, these strings are
 defined as class-level attributes which can be overridden at the instance
 level when desired. The names of the attributes are default_time_format
 (for the strptime format string) and default_msec_format (for appending
 the millisecond value).
 }}}

 Since the date time output is not created via one format operation it is
 more complicated than just adding %Z or %z to the format string.

 Happy to do the work.  Please provide feedback/direction.

--

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

[Django] #31537: Optionally log server_time with timzone

[Django]

#31537: Optionally log server_time with timzone
-+
   Reporter:  thenewguy  |  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  |
-+
 It would be helpful if logging format included the timezone for the logged
 time.  When this information is parsed (for example logging aggregation
 using logstash and the elastic stack) the timezone data would be very
 helpful so the time is correct.

 For reference, https://docs.python.org/3/library/logging.html
 {{{
 Changed in version 3.3: Previously, the default format was hard-coded as
 in this example: 2010-09-06 22:38:15,292 where the part before the comma
 is handled by a strptime format string ('%Y-%m-%d %H:%M:%S'), and the part
 after the comma is a millisecond value. Because strptime does not have a
 format placeholder for milliseconds, the millisecond value is appended
 using another format string, '%s,%03d' — and both of these format strings
 have been hardcoded into this method. With the change, these strings are
 defined as class-level attributes which can be overridden at the instance
 level when desired. The names of the attributes are default_time_format
 (for the strptime format string) and default_msec_format (for appending
 the millisecond value).
 }}}

 Since the date time output is not created via one format operation it is
 more complicated than just adding %Z or %z to the format string

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

Re: [Django] #25236: Remove ifequal from the template language

[Django]

#25236: Remove ifequal from the template language
-+-
 Reporter:  Daniel Greenfeld |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jon Dufresne):

 The following quick and dirty script will update a codebase to the newer
 `{% if %}` syntax. This will update files in place, so please be sure to
 backup your code first, preferably with SCM. You should examine the
 results of the diff for correctness before accepting.

 {{{
 find $(find -name templates) -type f -exec perl -pi -e 's/{% *ifequal
 +(.+?) +(.+?) *%}/{% if $1 == $2 %}/;' -e 's/{% *endifequal *%}/{% endif
 %}/;' -e 's/{% *ifnotequal +(.+?) +(.+?) *%}/{% if $1 != $2 %}/;' -e 's/{%
 *endifnotequal *%}/{% endif %}/;' {} \;
 }}}

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

Re: [Django] #31536: Disabled clearable file field widget is not disabling the checkbox

[Django]

#31536: Disabled clearable file field widget is not disabling the checkbox
-+-
 Reporter:  Carles Pina Estany   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  form, filefield, | Triage Stage:
  clearable_file_input   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-

Comment (by Carles Pina Estany):

 If the fix looked good I'm happy to re-write the commit message to past
 tense and with "fixed"

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

Re: [Django] #31535: Calling annotate with a case statement that references a recursive many to many relationship creates duplicates.

[Django]

#31535: Calling annotate with a case statement that references a recursive many 
to
many relationship creates duplicates.
-+-
 Reporter:  David Cooke  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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
-+-

Comment (by Simon Charette):

 The ORM is able to optimize `.filter(unlocked_by__in=solved_challenges)`
 into an `INNER JOIN` but it cannot do the same for annotations because it
 could be doing some special handling of `NULL` and it would require some
 pretty sophisticated introspection to determine it's safe to do. It would
 also be backward incompatible at this point. You should rely on `Subquery`
 or even `Exists` in your reported case instead.

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

Re: [Django] #31535: Calling annotate with a case statement that references a recursive many to many relationship creates duplicates. (was: Calling annotate with a case statement that references a rec

[Django]

#31535: Calling annotate with a case statement that references a recursive many 
to
many relationship creates duplicates.
-+-
 Reporter:  David Cooke  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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


Comment:

 This is documented behavior (see the warning in the
 [https://docs.djangoproject.com/en/dev/ref/models/querysets/#values
 QuerySet.values() docs]):

  Because `ManyToManyField` attributes and reverse relations can have
 multiple related rows, including these can have a multiplier effect on the
 size of your result set. This will be especially pronounced if you include
 multiple such fields in your `values()` query, in which case all possible
 combinations will be returned.

 You can use `Subquery()` or `.distinct(...)` to avoid duplicate.

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

Re: [Django] #31536: Disabled clearable file field widget is not disabling the checkbox

[Django]

#31536: Disabled clearable file field widget is not disabling the checkbox
-+-
 Reporter:  Carles Pina Estany   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  form, filefield, | Triage Stage:
  clearable_file_input   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-

Comment (by Carles Pina Estany):

 Possible fix: https://github.com/cpina/django/tree/ticket_31536 (or
 attached as a patch)

 Let me know if I can do anything else - if a unit test needs to be
 improved or added I can have a look, I'm new here and I haven't looked yet
 if templates have accompanying unit tests but I thought of sending the
 patch for 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/063.ec05e02a67b537a4e8d20d8570a780be%40djangoproject.com.

Re: [Django] #31536: Disabled clearable file field widget is not disabling the checkbox

[Django]

#31536: Disabled clearable file field widget is not disabling the checkbox
-+-
 Reporter:  Carles Pina Estany   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  form, filefield, | Triage Stage:
  clearable_file_input   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Carles Pina Estany):

 * Attachment "31536-clearable_file_input_disabled.patch" added.

 Possible patch for the described problem

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

[Django] #31536: Disabled clearable file field widget is not disabling the checkbox

[Django]

#31536: Disabled clearable file field widget is not disabling the checkbox
-+-
   Reporter:  Carles |  Owner:  nobody
  Pina Estany|
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Forms  |Version:  master
   Severity:  Normal |   Keywords:  form, filefield,
   Triage Stage: |  clearable_file_input
  Unreviewed |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  1  |
-+-
 Using a forms.FileField with a disabled widget is disabling the "Browse"
 button but not the checkbox to "Clear" the file.

 Checking the checkbox and submitting cause no effect since the widget is
 disabled but the UI is confusing.

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

Re: [Django] #31534: Deprecate django.conf.urls.url().

[Django]

#31534: Deprecate django.conf.urls.url().
-+-
 Reporter:  David Smith  |Owner:  David
 Type:   |  Smith
  Cleanup/optimization   |   Status:  assigned
Component:  Core (URLs)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by David Smith):

 * owner:  nobody => David Smith
 * 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/066.b446fe07d98a7dcd428184e6d8831c89%40djangoproject.com.

Re: [Django] #31535: Calling annotate with a case statement that references a recursive many to many relationship on the same model as the queryset will create duplicates

[Django]

#31535: Calling annotate with a case statement that references a recursive many 
to
many relationship on the same model as the queryset will create duplicates
-+-
 Reporter:  david-cooke  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by david-cooke:

Old description:

> So I have a Challenge model that has an unlocks field which is a
> recursive, asymmetric many to many field with a reverse name of
> unlocked_by. I call annotate on it to add an "unlocked" field which
> checks if the challenges unlocked_by contains any ids in a list of solved
> challenges, doing this inserts all the solved challenges into the
> queryset that annotate is being called on. There's an example of this
> here: https://github.com/david-cooke/djangobug/blob/master/bug/tests.py
>
> The sql being run is
> {{{
> SELECT "bug_challenge"."id", "bug_challenge"."name", CASE WHEN
> "bug_challenge_unlocks"."from_challenge_id" IN (5, 1) THEN True ELSE
> False END AS "unlocked" FROM "bug_challenge" LEFT OUTER JOIN
> "bug_challenge_unlocks" ON ("bug_challenge"."id" =
> "bug_challenge_unlocks"."to_challenge_id")
> }}}
> so it seems like the left outer join is adding the duplicates.
>
> It is possible to work around this by calling
> value_list(flat=True).distinct('pk') however isn't compatible with more
> complicated examples such as
> https://github.com/ractf/core/blob/master/challenge/views.py#L50

New description:

 So I have a Challenge model that has an unlocks field which is a
 recursive, asymmetric many to many field with a reverse name of
 unlocked_by. I call annotate on it to add an "unlocked" field which checks
 if the challenges unlocked_by contains any ids in a list of solved
 challenges, doing this inserts all the solved challenges into the queryset
 that annotate is being called on. There's an example of this here:
 https://github.com/david-cooke/djangobug/blob/master/bug/tests.py

 The sql being run is
 {{{
 SELECT "bug_challenge"."id", "bug_challenge"."name", CASE WHEN
 "bug_challenge_unlocks"."from_challenge_id" IN (5, 1) THEN True ELSE False
 END AS "unlocked" FROM "bug_challenge" LEFT OUTER JOIN
 "bug_challenge_unlocks" ON ("bug_challenge"."id" =
 "bug_challenge_unlocks"."to_challenge_id")
 }}}
 so it seems like the left outer join is adding the duplicates although
 thats needed for the case statement.

 It is possible to work around this by calling
 value_list(flat=True).distinct('pk') however isn't compatible with more
 complicated examples such as
 https://github.com/ractf/core/blob/master/challenge/views.py#L50

--

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

[Django] #31535: Calling annotate with a case statement that references a recursive many to many relationship on the same model as the queryset will create duplicates

[Django]

#31535: Calling annotate with a case statement that references a recursive many 
to
many relationship on the same model as the queryset will create duplicates
-+-
   Reporter:  david- |  Owner:  nobody
  cooke  |
   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  |
-+-
 So I have a Challenge model that has an unlocks field which is a
 recursive, asymmetric many to many field with a reverse name of
 unlocked_by. I call annotate on it to add an "unlocked" field which checks
 if the challenges unlocked_by contains any ids in a list of solved
 challenges, doing this inserts all the solved challenges into the queryset
 that annotate is being called on. There's an example of this here:
 https://github.com/david-cooke/djangobug/blob/master/bug/tests.py

 The sql being run is
 {{{
 SELECT "bug_challenge"."id", "bug_challenge"."name", CASE WHEN
 "bug_challenge_unlocks"."from_challenge_id" IN (5, 1) THEN True ELSE False
 END AS "unlocked" FROM "bug_challenge" LEFT OUTER JOIN
 "bug_challenge_unlocks" ON ("bug_challenge"."id" =
 "bug_challenge_unlocks"."to_challenge_id")
 }}}
 so it seems like the left outer join is adding the duplicates.

 It is possible to work around this by calling
 value_list(flat=True).distinct('pk') however isn't compatible with more
 complicated examples such as
 https://github.com/ractf/core/blob/master/challenge/views.py#L50

-- 
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/054.ee99900bf7e80be51263b69c863dd008%40djangoproject.com.

Re: [Django] #30573: Don't assume that things are "easy"/"obvious"/"simple" in the docs.

[Django]

#30573: Don't assume that things are "easy"/"obvious"/"simple" in the docs.
-+-
 Reporter:  Tobias Kunze |Owner:  Tobias
 Type:   |  Kunze
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  master
 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:"d17b380653da5f95885ce53468fe7aac60672841" d17b3806]:
 {{{
 #!CommitTicketReference repository=""
 revision="d17b380653da5f95885ce53468fe7aac60672841"
 Refs #30573 -- Rephrased "Of Course" and "Obvious(ly)" in documentation
 and comments.
 }}}

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

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

Re: [Django] #31534: Deprecate django.conf.urls.url(). (was: Depreciate django.conf.urls.url)

[Django]

#31534: Deprecate django.conf.urls.url().
--+
 Reporter:  David Smith   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (URLs)   |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by felixxm):

 * type:  Uncategorized => Cleanup/optimization
 * component:  Uncategorized => Core (URLs)
 * version:  3.0 => master
 * stage:  Unreviewed => Accepted


Comment:

 Agreed. We can deprecate it in Django 3.1 and remove in Django 4.0.
 Aymeric [https://groups.google.com/d/msg/django-
 developers/D44LSp0bPg8/hKybIqNiBAAJ proposed] to deprecate it in Django
 3.1 when we discussed DEP 201.

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

Re: [Django] #30372: Django (moderately) High CPU usage at Idle

[Django]

#30372: Django (moderately) High CPU usage at Idle
-+-
 Reporter:  Benjamin Schollnick  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  2.2
 Severity:  Normal   |   Resolution:  needsinfo
 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 Mariusz Felisiak ):

 In [changeset:"c00bc27945d195295101c695e2a901b06b10fe96" c00bc279]:
 {{{
 #!CommitTicketReference repository=""
 revision="c00bc27945d195295101c695e2a901b06b10fe96"
 Refs #30372 -- Stopped watching built-in Django translation files by auto-
 reloader.
 }}}

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

Re: [Django] #31522: FilteredSelectMultiple widget jumps to top when an option is added.

[Django]

#31522: FilteredSelectMultiple widget jumps to top when an option is added.
-+-
 Reporter:  Shai Berger  |Owner:
 Type:   |  TapanGujjar
  Cleanup/optimization   |   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:  1
Easy pickings:  1|UI/UX:  1
-+-
Changes (by felixxm):

 * needs_better_patch:  0 => 1


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

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