Re: [Django] #33626: django.db.models.query_utils.RegisterLookupMixin._unregister_lookup method also should clear the cache stored for django.db.models.query_utils.RegisterLookupMixin.get_lookups

[Django]

#33626: django.db.models.query_utils.RegisterLookupMixin._unregister_lookup 
method
also should clear the cache stored for
django.db.models.query_utils.RegisterLookupMixin.get_lookups
-+-
 Reporter:  Himanshu |Owner:  Himanshu
  Balasamanta|  Balasamanta
 Type:  Bug  |   Status:  assigned
Component:  Error reporting  |  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  Lookups, caching,| Triage Stage:
  ORM|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 Hi Himanshu. This may be right, yes — I need to have a sit-down and play
 with it.

 **Main question**: Are you able to put together an example case where the
 wrong result arrises?

 * I was looking at [https://github.com/django/django/pull/6906 PR #6906]
 which added the cache clearing.
 * Also noting the `For use in tests only...` in the `_unregister_lookup`
 docstring. So this would show up in a test interdependency...? 🤔

-- 
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/0107018007e8d373-ea8284f1-7ab9-4283-bb14-5b9470703f3a-00%40eu-central-1.amazonses.com.

[Django] #33626: django.db.models.query_utils.RegisterLookupMixin._unregister_lookup method also should clear the cache stored for django.db.models.query_utils.RegisterLookupMixin.get_lookups

[Django]

#33626: django.db.models.query_utils.RegisterLookupMixin._unregister_lookup 
method
also should clear the cache stored for
django.db.models.query_utils.RegisterLookupMixin.get_lookups
-+-
   Reporter:  Himanshu   |  Owner:  Himanshu
  Balasamanta|  Balasamanta
   Type:  Bug| Status:  assigned
  Component:  Error  |Version:  4.0
  reporting  |   Keywords:  Lookups, caching,
   Severity:  Normal |  ORM
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 In current source code, in the **_unregister_lookup** method,
 
[https://github.com/django/django/blame/main/django/db/models/query_utils.py#L212],
 the cache is not cleared, which should be done, as it is done in
 **register_lookup**,
 
https://github.com/django/django/blame/main/django/db/models/query_utils.py#L202.
 Corresponding to this change, minor changes need to be brought in the
 **schema.tests.SchemaTests.test_func_unique_constraint_lookups** test.

-- 
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/0107018007d4de01-7586d40e-aa83-473a-8aed-8c571ac5c0f9-00%40eu-central-1.amazonses.com.

Re: [Django] #33624: Only disable console logging when ADMINS is set

[Django]

#33624: Only disable console logging when ADMINS is set
-+--
 Reporter:  Alex Dehnert |Owner:  (none)
 Type:  Uncategorized|   Status:  closed
Component:  Error reporting  |  Version:  4.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by Carlton Gibson):

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


Comment:

 HI Alex.

 > ... and ADMINS is non-empty ...

 The `mail_admins` function, used by AdminEmailHandler already includes a
 check for this:


 {{{
 def mail_admins(
 subject, message, fail_silently=False, connection=None,
 html_message=None
 ):
 """Send a message to the admins, as defined by the ADMINS setting."""
 if not settings.ADMINS:
 return
 }}}

 
[https://github.com/django/django/blob/0b31e024873681e187b574fe1c4afe5e48aeeecf/django/core/mail/__init__.py#L117-L122
 Src]

 The `ADMINS` setting is discussed multiple times in the docs, but
 explicitly in the
 [https://docs.djangoproject.com/en/4.0/howto/deployment/checklist/#admins-
 and-managers deployment checklist], and
 [https://docs.djangoproject.com/en/4.0/howto/error-reporting/#email-
 reports error reporting documentation]. For me, I think that sufficient
 really.

-- 
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/0107018007d2ef7c-dc4d8022-fbfa-42cb-8ca6-5ae016161d23-00%40eu-central-1.amazonses.com.

Re: [Django] #33625: Under ASGI, PyLibMCCache closes memcached connection after every request

[Django]

#33625: Under ASGI, PyLibMCCache closes memcached connection after every request
--+
 Reporter:  Anders Kaseorg|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Cache system)   |  Version:  4.0
 Severity:  Normal|   Resolution:
 Keywords:  asgi, async   | 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):

 * keywords:   => asgi, async
 * stage:  Unreviewed => Accepted


Comment:

 I didn't test, but seems reasonable. Thanks for the report Anders.

 (If you could attach a reproducing project with exact steps, that would
 save a cycle later.)

-- 
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/0107018007c6a57d-d7c33455-d1a7-46f9-ba1e-08aa30234b5a-00%40eu-central-1.amazonses.com.

Re: [Django] #33497: Database persistent connections do not work with ASGI in 4.0

[Django]

#33497: Database persistent connections do not work with ASGI in 4.0
-+-
 Reporter:  Stenkar  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ASGI; Database   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Anders Kaseorg):

 * cc: Anders Kaseorg (added)


Comment:

 Possibly related: #33625 (for memcached connections).

-- 
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/010701800774d8f7-4bef4a83-b544-4e1c-a2ba-e2ba9aae7c65-00%40eu-central-1.amazonses.com.

Re: [Django] #33625: Under ASGI, PyLibMCCache closes memcached connection after every request

[Django]

#33625: Under ASGI, PyLibMCCache closes memcached connection after every request
-+-
 Reporter:  Anders Kaseorg   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Cache system)  |  Version:  4.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
-+-

Comment (by Anders Kaseorg):

 Possibly related: #33497 (for database connections).

-- 
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/0107018007743644-0fe4b867-4d32-4ce5-8b19-607dbcbe10de-00%40eu-central-1.amazonses.com.

[Django] #33625: Under ASGI, PyLibMCCache closes memcached connection after every request

[Django]

#33625: Under ASGI, PyLibMCCache closes memcached connection after every request
+
   Reporter:  Anders Kaseorg|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Core (Cache system)   |Version:  4.0
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 When I run an application that uses
 `django.core.cache.backends.memcached.PyMemcacheCache` with WSGI under
 Gunicorn, it makes a single connection to memcached and leaves it open, as
 I expect.

 But when I run it with ASGI under uvicorn, it makes a different connection
 to memcached for every request and immediately closes it. That is,
 #11331/#15324 has returned. This at least adds undesirable latency, and
 may also eventually lead to connection failures as described in #11331.

 I think this happens because e3f6e18513224c8ad081e5a19da641f49b0b43da
 switched the thread-local cache objects to task-local cache objects. That
 was justified in #31253 by “a potential race condition if two coroutines
 touch the same cache object at exactly the same time”. But that
 justification doesn’t make sense: two coroutines ''cannot'' be running the
 same ''synchronous'' code on the same thread at the same time, so thread-
 local objects were already safe.

 Now that asynchronous cache backend support is being developed, the
 argument is slightly different—but it seems obvious to expect that any
 asynchronous cache backend should at least properly support concurrent use
 from multiple asynchronous tasks on the same thread, so thread-local
 objects should still be safe.

-- 
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/01070180074df828-9409a1b4-6e74-4736-9490-7a0d290552ca-00%40eu-central-1.amazonses.com.

Re: [Django] #13883: SelectBox.js with grouping (optgroup elements)

[Django]

#13883: SelectBox.js with grouping (optgroup elements)
-+-
 Reporter:  SardarNL |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  admin, SelectBox,| Triage Stage:  Accepted
  optgroup, sprintdec2010|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  1
-+-

Comment (by Michael McLarnon):

 Created PR: https://github.com/django/django/pull/15568

-- 
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/010701800630bf19-803b948b-b40f-4504-8059-f9a64da8c485-00%40eu-central-1.amazonses.com.

[Django] #33624: Only disable console logging when ADMINS is set

[Django]

#33624: Only disable console logging when ADMINS is set
---+
   Reporter:  Alex Dehnert |  Owner:  (none)
   Type:  Uncategorized| Status:  new
  Component:  Error reporting  |Version:  4.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|
---+
 The current [https://docs.djangoproject.com/en/4.0/ref/logging/#default-
 logging-conditions logging defaults] are:
 * If DEBUG=True, log to console
 * If DEBUG=False, use AdminEmailHandler

 In practice, I think this means if you set DEBUG=False and don't touch
 anything else, errors just vanish -- ADMINS defaults to [], so the emails
 don't actually go anywhere. The stock settings.py doesn't even mention
 ADMINS as something you might want to set, so this mistake seems very easy
 to make. (Also, empirically I made it.)

 Perhaps the logging defaults should be:
 * If DEBUG=True or ADMINS is empty, log to console
 * If DEBUG=False and ADMINS is non-empty, send emails

 (Alternatively, ADMINS could be added to the settings.py template, and
 perhaps a [https://docs.djangoproject.com/en/4.0/topics/checks/ system
 check] could be added to verify it's populated?)

 (I suspect the patch here is easy, but it seems like it requires a ~design
 decision that it's desirable.)

-- 
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/0107018005d3b1de-8b9b2656-dfc2-4270-832e-893314196457-00%40eu-central-1.amazonses.com.

Re: [Django] #33623: Inconsistent naturaltime strings in pt-br

[Django]

#33623: Inconsistent naturaltime strings in pt-br
-+-
 Reporter:  Daniel Brito |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  4.0
  Internationalization   |
 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, however, translations are handled at
 
[https://docs.djangoproject.com/en/dev/internals/contributing/localizing/#translations.
 Transifex] and not in this tracker.

-- 
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/01070180050f44e7-2f5bb690-92b9-45c3-b0d9-7cdf959814ac-00%40eu-central-1.amazonses.com.

[Django] #33623: Inconsistent naturaltime strings in pt-br

[Django]

#33623: Inconsistent naturaltime strings in pt-br
+
   Reporter:  Daniel Brito  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  Internationalization  |Version:  4.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 |
+
 Inconsistent strings generated by naturaltime in pt-br when the datetime
 value is more than a day old or more than one day in the future.

 Below are some examples:

 Actual result:  {{{1 day, 2 hoursatrás}}}. Expected result: {{{1 dia, 2
 horas atrás}}}
 Actual result: {{{2 days, 21 hours a partir de agora}}}. Expected result:
 {{{2 dias, 21 horas a partir de agora}}}

 Note that the en and pt-br terms are mixed. Furthermore, there is no space
 between the datetime and word "atrás".

-- 
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/0107018004d53474-cdae2e92-e233-48db-98c2-b4ca18066313-00%40eu-central-1.amazonses.com.

Re: [Django] #32559: Add attribute 'step' to FloatField.

[Django]

#32559: Add attribute 'step' to FloatField.
-+-
 Reporter:  Jacob Rief   |Owner:  Jacob
 |  Rief
 Type:  New feature  |   Status:  assigned
Component:  Forms|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  FloatField,  | Triage Stage:  Accepted
  NumberInput, step  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * 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/010701800465a8d8-03df5a2c-c6cd-463c-aa08-c5e515514143-00%40eu-central-1.amazonses.com.

Re: [Django] #33618: Wrong behavior on queryset update when multiple inheritance

[Django]

#33618: Wrong behavior on queryset update when multiple inheritance
-+-
 Reporter:  Sonicold |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  queryset update  | Triage Stage:  Ready for
  mutiple inheritance|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Sonicold):

 Replying to [comment:12 Carlton Gibson]:
 > It would be Django 4.1.
 >
 > > Is there a big risk for us to patch manually the 4.x ?
 >
 > Assuming you have good tests you could fork, apply
 0b31e024873681e187b574fe1c4afe5e48aeeecf to a branch from `stable/4.0.x`.
 > That's essentially how we'd backport ourselves, by cherrypicking the
 commit to the release branch.
 >
 > To maintain that you would need to update your fork and rebase after
 each 4.0 point-release, but that's certainly do-able.
 >
 > You could then install via [https://pip.pypa.io/en/stable/topics/vcs-
 support/ Pip's VCS support].
 >
 > I can't judge the degree of ''risk'' per se, it depends on your team,
 and whether time is allocated for any issues that may arise.
 > (Part of the reasoning behind the backport policy is that release
 branches should be largely stable though.)
 >
 > I hope that helps.
 >
 >

 Yes that helped, thanks a lot !

-- 
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/01070180042e64ba-9b9ebfcf-d23c-409d-9516-5badbd763f40-00%40eu-central-1.amazonses.com.

Re: [Django] #33618: Wrong behavior on queryset update when multiple inheritance

[Django]

#33618: Wrong behavior on queryset update when multiple inheritance
-+-
 Reporter:  Sonicold |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  queryset update  | Triage Stage:  Ready for
  mutiple inheritance|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 It would be Django 4.1.

 > Is there a big risk for us to patch manually the 4.x ?

 Assuming you have good tests you could fork, apply
 0b31e024873681e187b574fe1c4afe5e48aeeecf to a branch from `stable/4.0.x`.
 That's essentially how we'd backport ourselves, by cherrypicking the
 commit to the release branch.

 To maintain that you would need to update your fork and rebase after each
 4.0 point-release, but that's certainly do-able.

 You could then install via [https://pip.pypa.io/en/stable/topics/vcs-
 support/ Pip's VCS support].

 I can't judge the degree of ''risk'' per se, it depends on your team, and
 whether time is allocated for any issues that may arise.
 (Part of the reasoning behind the backport policy is that release branches
 should be largely stable though.)

 I hope that helps.

-- 
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/01070180042790ac-b0b8051b-4f82-435f-bd94-590ae4fd982e-00%40eu-central-1.amazonses.com.

Re: [Django] #33618: Wrong behavior on queryset update when multiple inheritance

[Django]

#33618: Wrong behavior on queryset update when multiple inheritance
-+-
 Reporter:  Sonicold |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  queryset update  | Triage Stage:  Ready for
  mutiple inheritance|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Sonicold):

 Replying to [comment:9 Carlton Gibson]:
 > Just commenting for completeness:
 >
 > > ... the issue has been around forever and only happens for uncommon
 model structures so I'd be wary of introducing a regression via a minor
 version if this was backported and possibly cause a different kind of data
 loss issue.
 >
 > I think this is the dominant point. I don't think we should backport.
 (So I agree with Mariusz.)

 Ok understood ! Do you think it will be added to next minor release
 4.04/4.05 or in 4.1 ? Is there a big risk for us to patch manually the 4.x
 ?

-- 
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/0107018004197566-329a3f78-1ea3-4558-b3d8-c3d76fb88391-00%40eu-central-1.amazonses.com.

Re: [Django] #32604: File uploads larger than FILE_UPLOAD_MAX_MEMORY_SIZE get wrong unix group based on setgid

[Django]

#32604: File uploads larger than FILE_UPLOAD_MAX_MEMORY_SIZE get wrong unix 
group
based on setgid
-+-
 Reporter:  Gavin Wahl   |Owner:  Mateo
 Type:   |  Radman
  Cleanup/optimization   |   Status:  assigned
Component:  File |  Version:  3.1
  uploads/storage|
 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 Mateo Radman):

 * needs_better_patch:  1 => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018003ff24a8-7209b551-9189-4734-b108-4252852a26be-00%40eu-central-1.amazonses.com.

Re: [Django] #32604: File uploads larger than FILE_UPLOAD_MAX_MEMORY_SIZE get wrong unix group based on setgid

[Django]

#32604: File uploads larger than FILE_UPLOAD_MAX_MEMORY_SIZE get wrong unix 
group
based on setgid
-+-
 Reporter:  Gavin Wahl   |Owner:  Mateo
 Type:   |  Radman
  Cleanup/optimization   |   Status:  assigned
Component:  File |  Version:  3.1
  uploads/storage|
 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/01070180037aeef7-aeb08a61-cd79-4c63-89e3-0c0c96b2e34c-00%40eu-central-1.amazonses.com.

Re: [Django] #33618: Wrong behavior on queryset update when multiple inheritance

[Django]

#33618: Wrong behavior on queryset update when multiple inheritance
-+-
 Reporter:  Sonicold |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  queryset update  | Triage Stage:  Ready for
  mutiple inheritance|  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:"0b31e024873681e187b574fe1c4afe5e48aeeecf" 0b31e024]:
 {{{
 #!CommitTicketReference repository=""
 revision="0b31e024873681e187b574fe1c4afe5e48aeeecf"
 Fixed #33618 -- Fixed MTI updates outside of primary key chain.
 }}}

-- 
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/0107018002efef34-c7c6f06b-adad-4a0e-bd9c-1f0af7747dc7-00%40eu-central-1.amazonses.com.

Re: [Django] #33618: Wrong behavior on queryset update when multiple inheritance

[Django]

#33618: Wrong behavior on queryset update when multiple inheritance
-+-
 Reporter:  Sonicold |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  queryset update  | Triage Stage:  Ready for
  mutiple inheritance|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 Just commenting for completeness:

 > ... the issue has been around forever and only happens for uncommon
 model structures so I'd be wary of introducing a regression via a minor
 version if this was backported and possibly cause a different kind of data
 loss issue.

 I think this is the dominant point. I don't think we should backport.  (So
 I agree with 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/0107018002e21d3d-39320832-c526-49a3-ad98-5ab0e09b4732-00%40eu-central-1.amazonses.com.