Re: [Django] #32926: Overriding admin site error

[Django]

#32926: Overriding  admin site error
---+--
 Reporter:  gojuukaze  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  3.2
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Mariusz Felisiak):

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


Comment:

 The current docs works for me. Maybe you created these files in an **app**
 directory not in an **project** directory. Duplicate of #32642 and #30598.

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

Re: [Django] #32925: TextField default text not populate to MySQL data when migrate

[Django]

#32925: TextField default text not populate to MySQL data when migrate
-+-
 Reporter:  Edgenius |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (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 Edgenius):

 I doubt if this need to  rely on database.  It can programatically update
 this default value to the existing columns when runs migrate.  At
 model.save(), it can save this default value to database.  Yes, I
 understand this need some tweak on migration code, but it most like an
 inconsistent from django, rather than database limitation.

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

Re: [Django] #32925: TextField default text not populate to MySQL data when migrate

[Django]

#32925: TextField default text not populate to MySQL data when migrate
-+-
 Reporter:  Edgenius |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (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 Mariusz Felisiak):

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


Comment:

 Thanks for the report, unfortunately there is not much we can do. MySQL
 8.0.13+ supports BLOB/TEXT defaults (see #30712) but it's really limited
 (see #32832).

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

[Django] #32926: Overriding admin site error

[Django]

#32926: Overriding  admin site error
-+
   Reporter:  gojuukaze  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  contrib.admin  |Version:  3.2
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 I got error when I overriding  admin site

 {{{
 Traceback (most recent call last):
   File "manage.py", line 25, in 
 main()
   File "manage.py", line 21, in main
 execute_from_command_line(sys.argv)
   File "/Users/xx/project/py38/lib/python3.8/site-
 packages/django/core/management/__init__.py", line 419, in
 execute_from_command_line
 utility.execute()
   File "/Users/xx/project/py38/lib/python3.8/site-
 packages/django/core/management/__init__.py", line 395, in execute
 django.setup()
   File "/Users/xx/project/py38/lib/python3.8/site-
 packages/django/__init__.py", line 24, in setup
 apps.populate(settings.INSTALLED_APPS)
   File "/Users/xx/project/py38/lib/python3.8/site-
 packages/django/apps/registry.py", line 93, in populate
 raise ImproperlyConfigured(
 django.core.exceptions.ImproperlyConfigured: Application labels aren't
 unique, duplicates: admin
 }}}

 I wrote the code based on tutorial
 (https://docs.djangoproject.com/en/3.2/ref/contrib/admin/#overriding-the-
 default-admin-site), and it works well on django 3.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/052.80b7029c872ad0e0c63fb94033930860%40djangoproject.com.

Re: [Django] #32925: TextField default text not populate to MySQL data when migrate

[Django]

#32925: TextField default text not populate to MySQL data when migrate
-+-
 Reporter:  Edgenius |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (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 Edgenius:

Old description:

> When adding 2 new fields, one is CharField and another is TextField, they
> both nullable with default value:
>
> {{{
> subject2 = models.CharField(max_length=512, blank=True, null=True,
> default="Some text")
> body2 = models.TextField(blank=True, null=True, default="Some text")
> }}}
>
> After migration in MySQL 8.0.19,  for existing data,  new CharField
> column populate that default "Some text" value. However,  TextField is
> just null.  This inconsistent behaviour is very confusing.

New description:

 When adding 2 new fields, one is CharField and another is TextField, they
 both nullable with default value:

 {{{
 subject2 = models.CharField(max_length=512, blank=True, null=True,
 default="Some text")
 body2 = models.TextField(blank=True, null=True, default="Some text")
 }}}

 After migration in MySQL 8.0.19,  for existing data,  new CharField column
 populate that default "Some text" value. However,  TextField is just null.
 This inconsistent behaviour is very confusing.

 Django version is 3.2.5.

--

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

[Django] #32925: TextField default text not populate to MySQL data when migrate

[Django]

#32925: TextField default text not populate to MySQL data when migrate
-+-
   Reporter: |  Owner:  nobody
  GeniusWiki |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.2
  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  |
-+-
 When adding 2 new fields, one is CharField and another is TextField, they
 both nullable with default value:

 {{{
 subject2 = models.CharField(max_length=512, blank=True, null=True,
 default="Some text")
 body2 = models.TextField(blank=True, null=True, default="Some text")
 }}}

 After migration in MySQL 8.0.19,  for existing data,  new CharField column
 populate that default "Some text" value. However,  TextField is just null.
 This inconsistent behaviour is very 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/053.078b111df2dfbe88dc0c0b339ed29559%40djangoproject.com.

Re: [Django] #32922: Adding "preferred_language" property to "HttpRequest" object

[Django]

#32922: Adding "preferred_language" property to "HttpRequest" object
+--
 Reporter:  Ruslan Semagin  |Owner:  nobody
 Type:  New feature |   Status:  closed
Component:  HTTP handling   |  Version:  3.2
 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 Nick Pope):

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


Comment:

 So unfortunately this is not as simple as what you have proposed for a
 number of reasons:

 - The `q` value for the priority of entries in the header should be taken
 into account
 [https://github.com/django/django/pull/14632#pullrequestreview-705530998
 as mentioned by Keryn].
 - The special `*` value shouldn't be returned as it isn't a valid
 language.
 - The value in `Accept-Language` may not be the user's "preferred"
 language. It is just the languages that the client is configured to
 accept.

 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-
 Language for more details.

 The good news is that Django has already implemented this and taken
 everything into consideration. Check out
 
[https://docs.djangoproject.com/en/stable/ref/utils/#django.utils.translation.get_language_from_request
 get_language_from_request()].

 Obviously this restricts the returned languages to those that are
 available in `settings.LANGUAGES`.

 If you really need to have the "preferred" and unadulterated value from
 the `Accept-Language` header, you could use the
 `parse_accept_lang_header()` function, but beware that this is an
 undocumented, private function.

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

Re: [Django] #32924: Move special-case logic in BoundField.initial() to BaseForm.get_initial_for_field()

[Django]

#32924: Move special-case logic in BoundField.initial() to
BaseForm.get_initial_for_field()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Forms|  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 Nick Pope):

 * stage:  Unreviewed => Accepted


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

Re: [Django] #32923: Add Field._clean_bound_field() to remove isinstance check in BaseForm._clean_fields()

[Django]

#32923: Add Field._clean_bound_field() to remove isinstance check in
BaseForm._clean_fields()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Forms|  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 Nick Pope):

 * stage:  Unreviewed => Accepted


Comment:

 Accepting in principle. The overhead of the extra method call is probably
 offset by the removal of the `isinstance()` check.

 ''(I'm basing the following on top of your changes in your
 [https://github.com/django/django/pull/14631 PR] for #32920.)''

 If I understand this correctly, then the idea is that we end up with
 changing this:

 {{{#!python
 # django/forms/forms.py

 class BaseForm:
 ...
 def _clean_fields(self):
 ...
 value = bf.initial if field.disabled else bf.data
 ...
 if isinstance(field, FileField):
 value = field.clean(value, bf.initial)
 else:
 value = field.clean(value)
 self.cleaned_data[name] = value
 ...
 }}}

 To this:

 {{{#!python
 # django/forms/fields.py

 class Field:
 ...
 def _clean_bound_field(self, bf):
 value = bf.initial if self.disabled else bf.data
 return self.clean(value)
 ...

 class FileField(Field):
 ...
 def _clean_bound_field(self, bf):
 value = bf.initial if self.disabled else bf.data
 return self.clean(value, bf.initial)
 ...

 # django/forms/forms.py

 class BaseForm:
 ...
 def _clean_fields(self):
 ...
 self.cleaned_data[name] = field._clean_bound_field(bf)
 ...
 }}}

 I have a few thoughts:

 - Would we want to use `value = field.bound_data(bf.data, bf.initial)` in
 `_clean_bound_field()`?[[BR]]`Field.bound_data()` implements the same
 logic, but is specialized in `FileField.bound_data()` and
 `JSONField.bound_data()`.[[BR]](I'm not sure whether not using the
 specialized logic is something we want for the value passed to `.clean()`
 or not...)
 - What about adding `initial=None` to the signature of
 `Field.clean()`?[[BR]]The advantage is that it takes away an extra layer
 of function calls, the signature of `Field.clean()` becomes unified for
 all fields, and we achieve the same simplification.[[BR]]The disadvantage
 is that we'd need to have a deprecation period using `inspect.signature()`
 as we'd be changing public API.
 - Is there a way we can do this without having to pass `initial` into
 `FileField.clean()` instead? It feels like this was hacked in for a niche
 edge 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/067.402c54f1b9eb686edd9e7662fdc104e6%40djangoproject.com.

Re: [Django] #32916: CsrfViewMiddleware's request.META["CSRF_COOKIE_USED"] and request.csrf_cookie_needs_reset can be combined

[Django]

#32916: CsrfViewMiddleware's request.META["CSRF_COOKIE_USED"] and
request.csrf_cookie_needs_reset can be combined
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  CSRF |  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
-+-

Comment (by Chris Jerdonek):

 > I do not have strong feelings on the request attr vs the META dict.
 Somehow META feels wrong, what is META supposed to be used for?

 Thanks, Florian. One advantage `META` has over a custom attribute is that
 its contents automatically get displayed in the debug view under "Request
 information" (which isn't currently true for custom attributes). So
 developers are able to see a snapshot of the CSRF "state" more easily when
 an error occurs. This is what I was referring to in part when I said above
 it's "more visible and easier to debug." Also, as long as we're using
 `META` to store `CSRF_COOKIE`, I think it makes sense to store the related
 values alongside. If we're considering moving `CSRF_COOKIE` out of there
 at some point, it's another story. Finally, while the debug view and tools
 could be updated to display certain custom attributes, it would create
 more friction when changing the attributes because the tools would also
 need to be updated.

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

Re: [Django] #31676: Document DEP 10 governance

[Django]

#31676: Document DEP 10 governance
-+-
 Reporter:  James Bennett|Owner:  James
 Type:   |  Bennett
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"8f59f72a20941c4869cb6cb0934c153562e378b3" 8f59f72a]:
 {{{
 #!CommitTicketReference repository=""
 revision="8f59f72a20941c4869cb6cb0934c153562e378b3"
 [2.2.x] Refs #31676 -- Removed Django Core-Mentorship mailing list
 references in docs.

 Backport of 37e8367c359cd115f109d82f99ff32be219f4928 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.124f2a52c558000e8afc9071387142a6%40djangoproject.com.

Re: [Django] #31676: Document DEP 10 governance

[Django]

#31676: Document DEP 10 governance
-+-
 Reporter:  James Bennett|Owner:  James
 Type:   |  Bennett
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"cb149dd1946c4ec5f15a8edd4df062d1c0a5e93a" cb149dd]:
 {{{
 #!CommitTicketReference repository=""
 revision="cb149dd1946c4ec5f15a8edd4df062d1c0a5e93a"
 [3.1.x] Refs #31676 -- Removed Django Core-Mentorship mailing list
 references in docs.

 Backport of 37e8367c359cd115f109d82f99ff32be219f4928 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.168bb68e0e2c6c193e9e8e79372aa324%40djangoproject.com.

Re: [Django] #31676: Document DEP 10 governance

[Django]

#31676: Document DEP 10 governance
-+-
 Reporter:  James Bennett|Owner:  James
 Type:   |  Bennett
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"f36edbc37826e5225a179b1318a7302b1b9e3bfa" f36edbc3]:
 {{{
 #!CommitTicketReference repository=""
 revision="f36edbc37826e5225a179b1318a7302b1b9e3bfa"
 [3.2.x] Refs #31676 -- Removed Django Core-Mentorship mailing list
 references in docs.

 Backport of 37e8367c359cd115f109d82f99ff32be219f4928 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.0483ff6e6fd14d671967b3c4a26738e3%40djangoproject.com.

Re: [Django] #31676: Document DEP 10 governance

[Django]

#31676: Document DEP 10 governance
-+-
 Reporter:  James Bennett|Owner:  James
 Type:   |  Bennett
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by GitHub ):

 In [changeset:"37e8367c359cd115f109d82f99ff32be219f4928" 37e8367c]:
 {{{
 #!CommitTicketReference repository=""
 revision="37e8367c359cd115f109d82f99ff32be219f4928"
 Refs #31676 -- Removed Django Core-Mentorship mailing list references in
 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/069.d939d2c071ffa8bd57520e8ef94e59d7%40djangoproject.com.

[Django] #32924: Move special-case logic in BoundField.initial() to BaseForm.get_initial_for_field()

[Django]

#32924: Move special-case logic in BoundField.initial() to
BaseForm.get_initial_for_field()
-+-
   Reporter:  Chris  |  Owner:  Chris Jerdonek
  Jerdonek   |
   Type: | Status:  assigned
  Cleanup/optimization   |
  Component:  Forms  |Version:  dev
   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  |
-+-
 This is another follow-up to ticket #32920.

 Currently, `BoundField.initial()` has logic to special-case `time` and
 `datetime` objects:
 
https://github.com/django/django/blob/f5669fd7b568cf8a3eda1e65c1c6fb583c7b177d/django/forms/boundfield.py#L217-L219
 I noticed that this logic can be moved to
 `BaseForm.get_initial_for_field()`, and in particular under the `if
 callable(value)` block:
 
https://github.com/django/django/blob/f5669fd7b568cf8a3eda1e65c1c6fb583c7b177d/django/forms/forms.py#L496-L497

 Eventually, I think it could make sense to go further and move some of
 this logic to a new method of the `Field` class, which could permit the
 special-casing to be handled by overriding in sub-classes that use times
 and datetimes.

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

[Django] #32923: Add Field._clean_bound_field() to remove isinstance check in BaseForm._clean_fields()

[Django]

#32923: Add Field._clean_bound_field() to remove isinstance check in
BaseForm._clean_fields()
-+-
   Reporter:  Chris  |  Owner:  Chris Jerdonek
  Jerdonek   |
   Type: | Status:  assigned
  Cleanup/optimization   |
  Component:  Forms  |Version:  3.2
   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  |
-+-
 This is a follow-up to ticket #32920.

 Currently, `BaseForm._clean_fields()` does an instance check for each
 field to special-case `FileField`:
 
https://github.com/django/django/blob/f5669fd7b568cf8a3eda1e65c1c6fb583c7b177d/django/forms/forms.py#L396-L400
 I noticed that if `Field` grows a `_clean_bound_field(bf)` method, then
 the special-casing could be handled by overriding `_clean_bound_field()`
 in `FileField`, and `_clean_fields()` would become simpler.

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

Re: [Django] #32921: Incorrect SQL generation for JSON has_key__in

[Django]

#32921: Incorrect SQL generation for JSON has_key__in
-+-
 Reporter:  Shaheed Haque|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (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 Mariusz Felisiak):

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


Comment:

 `has_key` cannot be chained with other lookups, if you do this it will be
 interpreted as a key lookup for `JSONField` as you observed. You should
 use [https://docs.djangoproject.com/en/3.2/topics/db/queries/#has-any-keys
 has_key_any]. If you're having trouble understanding how Django works, see
 TicketClosingReasons/UseSupportChannels for ways to get help.

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

Re: [Django] #21936: Allow delete to provide a success message through a mixin.

[Django]

#21936: Allow delete to provide a success message through a mixin.
-+-
 Reporter:  david.fischer.ch@…   |Owner:  Demetris
 |  Stavrou
 Type:  New feature  |   Status:  assigned
Component:  contrib.messages |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  mixin| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 [https://github.com/django/django/pull/14634 Updated 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/084.0223441a0a4d4ba96ba0465e547f14f9%40djangoproject.com.

Re: [Django] #32921: Incorrect SQL generation for JSON has_key__in

[Django]

#32921: Incorrect SQL generation for JSON has_key__in
-+-
 Reporter:  Shaheed Haque|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (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
-+-

Comment (by Shaheed Haque):

 Also, it turns out that an empty "array[]" gives rise to an error:
 {{{
 django.db.utils.ProgrammingError: cannot determine type of empty array
 LINE 1: ...021-06-12'::date AND (snapshot #> '{employee}' ?| array[])) ...
  ^
 HINT:  Explicitly cast to the desired type, for example
 ARRAY[]::integer[].
 }}}
 which I fixed by casting to an array of strings using **::varchar[]**
 (since JSON keys are always strings) like this:
 {{{
 qs = company.payrun_set.extra(where=[''' "paiyroll_payrun"."snapshot" #>
 '{employee}' ?| array[...is empty...]::varchar[] '''])
 }}}

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

Re: [Django] #32922: Adding "preferred_language" property to "HttpRequest" object

[Django]

#32922: Adding "preferred_language" property to "HttpRequest" object
---+--
 Reporter:  pixel365   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  3.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Description changed by pixel365:

Old description:

> Sometimes it is useful to get the client's preferred language from the
> request and then pass it somewhere, for example, apply a filter to fetch
> data.
> Therefore, it is useful to access this property in the object.
>

>
> {{{
> @property
> def preferred_language(self):
> """Returns the client's language in order of priority from the
> "Accept-Language" header"""
> languages = [_.strip() for _ in self.headers.get('Accept-Language',
> '*').split(',')]
> for language in languages:
> if language.split(';')[0] == language:
> return language
> return language.split(';')[0]
> return '*'
> }}}

New description:

 Sometimes it is useful to get the client's preferred language from the
 request and then pass it somewhere, for example, apply a filter to fetch
 data.
 Therefore, it is useful to access this property in the object.



 {{{
 @property
 def preferred_language(self):
 """Returns the client's language in order of priority from the
 "Accept-Language" header"""
 languages = [_.strip() for _ in self.headers.get('Accept-Language',
 '*').split(',')]
 return languages[0].split(';')[0]
 }}}

--

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

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

[Django] #32922: Adding "preferred_language" property to "HttpRequest" object

[Django]

#32922: Adding "preferred_language" property to "HttpRequest" object
-+
   Reporter:  pixel365   |  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  HTTP handling  |Version:  3.2
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 Sometimes it is useful to get the client's preferred language from the
 request and then pass it somewhere, for example, apply a filter to fetch
 data.
 Therefore, it is useful to access this property in the object.



 {{{
 @property
 def preferred_language(self):
 """Returns the client's language in order of priority from the
 "Accept-Language" header"""
 languages = [_.strip() for _ in self.headers.get('Accept-Language',
 '*').split(',')]
 for language in languages:
 if language.split(';')[0] == language:
 return language
 return language.split(';')[0]
 return '*'
 }}}

-- 
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/051.dda1fad855c792dec2041b28b6f20448%40djangoproject.com.

[Django] #32921: Incorrect SQL generation for JSON has_key__in

[Django]

#32921: Incorrect SQL generation for JSON has_key__in
-+-
   Reporter:  Shaheed|  Owner:  nobody
  Haque  |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.2
  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  |
-+-
 I have a Django 3.2.4 model with a JSONField (hosted on Postgres 12)
 called "snapshot" which contains employees like this:
 {{{
 {
 "employee": {
 "6": {...},
 "99": {...}
 }
 }
 }}}
 I would like to perform a .filter() on the presence of certain employee
 keys, so I tried this:
 {{{
 qs = company.payrun_set.filter(snapshot__employee__has_key__in=['6',
 '8'])
 }}}
 but this produces incorrect results. When I examine qs.query (which I know
 does not always produce an exact rendition), I see the  following
 incorrect SQL:
 {{{
 ...("paiyroll_payrun"."snapshot" #> ['employee', 'has_key']) IN ("6",
 "8")
 }}}
 Notice how **has_key** is treated as a literal key value. I believe the
 correct query can be formed like this:
 {{{
 qs = company.payrun_set.extra(where=[''' "paiyroll_payrun"."snapshot"
 #> '{employee}' ?| array['6', '8'] '''])
 }}}
 and the corresponding SQL fragment should then look like this (again from
 examining qs.query):
 {{{
..."paiyroll_payrun"."snapshot"#>'{employee}' ?| array['6', '8']
 }}}
 Basically, **has_key** followed by **in** should be converted into the "?|
 array[]".

 I'm not an expert, so would love to be corrected if I have misunderstood.

 Thanks, Shaheed

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

Re: [Django] #31750: Abstract model field should not be equal across models

[Django]

#31750: Abstract model field should not be equal across models
-+-
 Reporter:  Ryan Hiebert |Owner:  Ryan
 |  Hiebert
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 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
-+-

Comment (by Nicolas Delaby):

 Thanks for clarifying Mariusz.

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

Re: [Django] #24900: KeyError when trying to migrate to a replaced migration

[Django]

#24900: KeyError when trying to migrate to a replaced migration
+---
 Reporter:  Carl Meyer  |Owner:  Jacob Walls
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  dev
 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 Asif Saifuddin Auvi):

 * version:  1.8 => dev


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

Re: [Django] #32920: BaseForm's _clean_fields() and changed_data should access values via BoundField

[Django]

#32920: BaseForm's _clean_fields() and changed_data should access values via
BoundField
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Forms|  Version:  dev
 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 Chris Jerdonek):

 * has_patch:  0 => 1


Comment:

 PR: https://github.com/django/django/pull/14631

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

Re: [Django] #32916: CsrfViewMiddleware's request.META["CSRF_COOKIE_USED"] and request.csrf_cookie_needs_reset can be combined

[Django]

#32916: CsrfViewMiddleware's request.META["CSRF_COOKIE_USED"] and
request.csrf_cookie_needs_reset can be combined
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  CSRF |  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
-+-

Comment (by Florian Apolloner):

 I'd love to get rid of one of those. I tried in the past and failed :D I
 do not have strong feelings on the request attr vs the `META` dict.
 Somehow `META` feels wrong, what is `META` supposed to be used for? http-
 headers and wsgi attributes, or should we also stuff our things in there?

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

Re: [Django] #31596: ForeignKey.validate() should validate using the base manager.

[Django]

#31596: ForeignKey.validate() should validate using the base manager.
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  model form   | 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 Damiox):

 Hello. The documentation for v2.2
 (https://docs.djangoproject.com/en/2.2/topics/db/managers/#using-managers-
 for-related-object-access) is stating that the base manager will be used
 in that version too instead of the default manager. We just saw that this
 fix has been released 12 days ago for v3.2.5, we were wondering when it'll
 be released for v2.2? 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/067.0e0efe9a353b508d178e53872a10ae3c%40djangoproject.com.

Re: [Django] #32905: Add `nonform` CSS class for non form errors in FormSets

[Django]

#32905: Add `nonform` CSS class for non form errors in FormSets
-+-
 Reporter:  Ties Jan Hefting |Owner:  Ties Jan
 |  Hefting
 Type:  New feature  |   Status:  assigned
Component:  Forms|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by 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/065.08236020b01eb63c68cfd3f9c8e7a9d5%40djangoproject.com.

Re: [Django] #32899: enhance JSONResponse safe=True kwarg docs

[Django]

#32899: enhance JSONResponse safe=True kwarg docs
-+-
 Reporter:  Thomas Grainger  |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  3.2
 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:"f5669fd7b568cf8a3eda1e65c1c6fb583c7b177d" f5669fd]:
 {{{
 #!CommitTicketReference repository=""
 revision="f5669fd7b568cf8a3eda1e65c1c6fb583c7b177d"
 Fixed #32899 -- Added note about avoiding non-dict objects in JsonResponse
 docs.

 Co-authored-by: Mariusz Felisiak 
 }}}

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

Re: [Django] #32899: enhance JSONResponse safe=True kwarg docs

[Django]

#32899: enhance JSONResponse safe=True kwarg docs
-+-
 Reporter:  Thomas Grainger  |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  3.2
 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):

 * 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/067.b7632175a1e5243db1bb62c759d56d9a%40djangoproject.com.

Re: [Django] #32919: Micro-optimisations for lexing & parsing of templates.

[Django]

#32919: Micro-optimisations for lexing & parsing of templates.
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  Cleanup/optimization   |   Status:  assigned
Component:  Template 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:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * cc: Nick Pope (added)
 * stage:  Unreviewed => Accepted


Comment:

 Hey Keryn. Thanks for this.

 Really nice analysis, and the PR looks reasonable in terms of
 comprehensibility/maintainability, so a speed-up to the DTL is +1.

 I'll cc Nick, as it strikes me as the kind of thing he likes :)

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

Re: [Django] #32913: test_glob inside utils_tests.test_autoreload.WatchmanReloaderTests is flaky

[Django]

#32913: test_glob inside utils_tests.test_autoreload.WatchmanReloaderTests is 
flaky
-+-
 Reporter:  Abhyudai |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Testing framework|  Version:  dev
 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
-+-
Changes (by Carlton Gibson):

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


Comment:

 I'm going to have to say `needsinfo` for now.

 Looks like it's an issue in `pywatchman`:

 {{{
   File "../django/venv/lib/python3.8/site-
 packages/pywatchman/__init__.py", line 344, in readBytes
 raise SocketTimeout('timed out waiting for response')
 pywatchman.SocketTimeout: timed out waiting for response, while executing
 ('watch-project', '/tmp/django_p9emwuc2/tmpdx4bsuny')
 }}}

 Is that timeout configurable maybe? 樂

 If we can identify a specific issue in Django, or a specific change we can
 make to work around the issue, we can reopen.

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

Re: [Django] #32880: Improve logging documentation

[Django]

#32880: Improve logging documentation
-+-
 Reporter:  Daniele Procida  |Owner:  Daniele
 Type:   |  Procida
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  logging  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by GitHub ):

 In [changeset:"22fbebc7444c8974f101c146f0fc18fe64ab48f6" 22fbebc]:
 {{{
 #!CommitTicketReference repository=""
 revision="22fbebc7444c8974f101c146f0fc18fe64ab48f6"
 Refs #32880 -- Made some titles consistent in how-to documents.

 This retitles documents for consistency, since some already (correctly)
 begin "How to...".
 }}}

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

Re: [Django] #32920: BaseForm's _clean_fields() and changed_data should access values via BoundField

[Django]

#32920: BaseForm's _clean_fields() and changed_data should access values via
BoundField
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Forms|  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 Carlton Gibson):

 * stage:  Unreviewed => Accepted


Comment:

 Hey Chris, this is interesting, and makes sense. :) — I think we should
 have a look at this yes. 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/067.fb65229c9483c4d994eef7ebce803f3e%40djangoproject.com.

Re: [Django] #32847: Adjust models.E025 system check for updated field descriptor setting.

[Django]

#32847: Adjust models.E025 system check for updated field descriptor setting.
-+-
 Reporter:  Carlton Gibson   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  dev
  (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 Carlton Gibson):

 Hi Hasan, thanks for looking.

 > I couldn't find a way to detect.

 Yes, that's likely. I'll have one more pass at it and see if I can come up
 with anything, but if not we can close. (It's a pretty niche config
 error...)

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

Re: [Django] #31750: Abstract model field should not be equal across models

[Django]

#31750: Abstract model field should not be equal across models
-+-
 Reporter:  Ryan Hiebert |Owner:  Ryan
 |  Hiebert
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 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
-+-

Comment (by Mariusz Felisiak):

 > Hi, I wonder if the submitted fix didn't introduce a subtle regression.

 This is an expected change IMO. Model fields don't make much sense without
 models (even abstract) so we should distinguish between fields in abstract
 models and the same fields inherited from them.

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

Re: [Django] #31750: Abstract model field should not be equal across models

[Django]

#31750: Abstract model field should not be equal across models
-+-
 Reporter:  Ryan Hiebert |Owner:  Ryan
 |  Hiebert
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 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
-+-

Comment (by Nicolas Delaby):

 Hi, I wonder if the submitted fix didn't introduce a subtle regression.
 Given the example posted in the description, how would you evaluate the
 following statements ?

 **before**
 
https://github.com/django/django/commit/502e75f9ed5476ffe8229109acf0c23999d4b533
 {{{#!python
 assert B._meta.get_field('myfield') == C._meta.get_field('myfield')
 assert B._meta.get_field('myfield') == A._meta.get_field('myfield')
 assert C._meta.get_field('myfield') == A._meta.get_field('myfield')
 }}}

 **after**
 
https://github.com/django/django/commit/502e75f9ed5476ffe8229109acf0c23999d4b533
 {{{#!python
 assert B._meta.get_field('myfield') != C._meta.get_field('myfield')
 assert B._meta.get_field('myfield') != A._meta.get_field('myfield')
 assert C._meta.get_field('myfield') != A._meta.get_field('myfield')
 }}}

 What if it shouldn't be this ? Since B (or C) doesn't override
 ''myfield'', I would expect the subclass to evaluate equality as if the
 field was defined on itself (given the parent model is abstract)
 **maybe?**
 {{{#!python
 assert B._meta.get_field('myfield') != C._meta.get_field('myfield')
 assert B._meta.get_field('myfield') == A._meta.get_field('myfield')
 assert C._meta.get_field('myfield') == A._meta.get_field('myfield')
 }}}

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

Re: [Django] #31685: Support updating conflicts with QuerySet.bulk_create().

[Django]

#31685: Support updating conflicts with QuerySet.bulk_create().
-+-
 Reporter:  Vitor Pereira|Owner:  Chih Sean
 |  Hsu
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  bulk insert update   | Triage Stage:  Accepted
  upsert |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|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/062.b91955aa2a5b0baec9ef6d3087a9e7a1%40djangoproject.com.