Re: [Django] #33563: Unapplying ContentType migration 0002 does not populate legacy name field on non-default database

2022-03-05 Thread Django
#33563: Unapplying ContentType migration 0002 does not populate legacy name 
field
on non-default database
-+-
 Reporter:  Hameed Gifford   |Owner:  Hameed
 |  Gifford
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  4.0
  contrib.contenttypes   |
 Severity:  Normal   |   Resolution:
 Keywords:  migrations   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Hameed Gifford):

 * owner:  nobody => Hameed Gifford
 * status:  new => assigned
 * has_patch:  0 => 1


Comment:

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

-- 
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/0107017f5e0f88dd-519b4daa-3710-41b8-8b1d-9526ffe75ee9-00%40eu-central-1.amazonses.com.


[Django] #33563: Unapplying ContentType migration 0002 does not populate legacy name field on non-default database

2022-03-05 Thread Django
#33563: Unapplying ContentType migration 0002 does not populate legacy name 
field
on non-default database
-+-
   Reporter:  Hameed |  Owner:  nobody
  Gifford|
   Type:  Bug| Status:  new
  Component: |Version:  4.0
  contrib.contenttypes   |
   Severity:  Normal |   Keywords:  migrations
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Given a database with the alias `other` that has all `contenttypes`
 migrations applied, roll the state back to initial:

 {{{#!bash
 $ manage.py migrate --database=other contenttypes 0001
 }}}

 All `ContentType` rows in the `other` database will be `null` instead of
 their intended value.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107017f5e09fbb1-11cda877-a161-4b44-b7cf-62e4a8feebeb-00%40eu-central-1.amazonses.com.


Re: [Django] #33308: Add psycopg3 backend

2022-03-05 Thread Django
#33308: Add psycopg3 backend
-+-
 Reporter:  Paolo Melchiorre |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  database postgresql  | Triage Stage:  Accepted
  backend orm|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Florian Apolloner):

 * cc: Florian Apolloner (added)


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107017f5b9464c4-2099a063-c05d-4606-9af8-1839cbe78bbd-00%40eu-central-1.amazonses.com.


Re: [Django] #7497: AppAdmin class for customizing app listing in admin index

2022-03-05 Thread Django
#7497: AppAdmin class for customizing app listing in admin index
---+
 Reporter:  mrts   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  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 Roman):

 To move things a little bit forward I have prepared a pull request based
 on this comment
 https://code.djangoproject.com/ticket/25671#comment:11

 https://github.com/django/django/pull/15483

-- 
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/0107017f5adaa0e9-068f14e4-2e58-4f34-8dca-246696227602-00%40eu-central-1.amazonses.com.


Re: [Django] #33561: Synchronize user attributes on every authentication with RemoteUserBackend

2022-03-05 Thread Django
#33561: Synchronize user attributes on every authentication with 
RemoteUserBackend
-+-
 Reporter:  Adrian Torres|Owner:  Adrian
 |  Torres
 Type:  New feature  |   Status:  closed
Component:  contrib.auth |  Version:  dev
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  RemoteUserBackend| Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Florian Apolloner):

 * cc: Florian Apolloner (added)


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107017f59e27cd2-fd3e183f-ff3e-48a7-812f-62efcea0096f-00%40eu-central-1.amazonses.com.


Re: [Django] #33561: Synchronize user attributes on every authentication with RemoteUserBackend

2022-03-05 Thread Django
#33561: Synchronize user attributes on every authentication with 
RemoteUserBackend
-+-
 Reporter:  Adrian Torres|Owner:  Adrian
 |  Torres
 Type:  New feature  |   Status:  closed
Component:  contrib.auth |  Version:  dev
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  RemoteUserBackend| Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Florian Apolloner):

 I think this would be a nice improvement. For one the suggested workaround
 does not work -- authentication checks could be done based on the assigned
 groups of the user which need to synchronized before `authenticate` calls
 into `user_can_authenticate` and not afterwards… This can be really useful
 with proxies like Authelia which sends along the following headers:
 `Remote-User, Remote-Groups, Remote-Name, Remote-Email`

 Given that this is security related I rather see us providing a hook at
 the proper place than having users patch around this. I am not sure I
 agree with the patch though, we already do have `configure_user` and it
 feels like we should just pass a boolean to that with the information if
 the user was just created or not (and move it around in code accordingly).

 @Mariusz I was hesitant to reopen and accept the ticket after you have
 closed it, but I think it would be useful to support this (also I want to
 check if trc sends mail properly now :D)

-- 
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/0107017f59e0c043-dd990071-c8e2-4389-854c-2eee06a585f0-00%40eu-central-1.amazonses.com.


Re: [Django] #31202: Bulk update suffers from poor performance with large numbers of models and columns

2022-03-05 Thread Django
#31202: Bulk update suffers from poor performance with large numbers of models 
and
columns
-+-
 Reporter:  Tom Forbes   |Owner:  Tom
 Type:   |  Forbes
  Cleanup/optimization   |   Status:  assigned
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 jerch):

 Some update on COPY FROM:

 Did a first playground implementation just to see the effects on
 performance, see
 https://gist.github.com/jerch/fd0fae0107ce7b153b7540111b2e89ab. The chart
 over there shows the mean runtime of 100 runs of x updated records in a
 100k table, updating just one integer field per record. The perf tests
 were done with plain postgres 14 docker image, with no tweaking of any
 settings.

 The implementation `copy_update` is not yet optimized for perf or neatly
 integrated yet, it is just to get an idea, where the ballpark for COPY
 FROM would end up. `bulk_update` is django's current implementation,
 `django-bulk-update` is from here: https://github.com/aykut/django-bulk-
 update, `fast_update` is my early impl of direct UPDATE FROM VALUES from
 above.

 Some observations from that:
 - `bulk_update` shows much worse runtime behavior than all others (thus
 accounting is stopped early)
 - `django-bulk-update` can keep up a bit longer, but then shows the same
 worse runtime growth (prolly due to the same SQL logic used?). This gets
 really worse for updates >5k (not shown).
 - `copy_update` has a much higher setup costs (1 to 256 updated records)
 - between 4096 to 8192 updates `copy_update` starts to pay off compared to
 `fast_update`, at 32k updates it is almost twice as fast
 - not shown in the charts: for higher updates counts it keeps gaining
 ground (almost being 4 times faster for 1M update records)
 - There is something going on between 256-512 updates, as almost all
 implementations show a steep jump there (postgres b-tree depth change? did
 not investigate that further...)

 Some early insights from that:
 - As already stated above in an earlier comment, django's `bulk_update` is
 currently pretty wasteful, as it even drops far behind `django-bulk-
 update`, which uses the same SQL update strategy.
 - `fast_update` is the winner in small to medium update counts, up to
 ~10k.
 - `copy_update` starts to shine for update counts >10k.

-- 
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/0107017f59d5943b-d6a06456-132d-47c9-8e4e-4ef988132a87-00%40eu-central-1.amazonses.com.


Re: [Django] #33552: SQLite JSONField() doesn't handle numerical has_key lookups

2022-03-05 Thread Django
#33552: SQLite JSONField() doesn't handle numerical has_key lookups
-+-
 Reporter:  TheTerrasque |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.0
  (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
-+-
Changes (by TheTerrasque):

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


Comment:

 Not a duplicate of #30566

 * This is django's models.JSONField() not postgres extension JSONField
 * It works as expected on Postgresql, the bug is on SQLite
 * #30566 goes directly against comments for
 https://code.djangoproject.com/ticket/29504

-- 
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/0107017f59d58c5d-b425b968-2ddf-4cf5-ad54-10586a486967-00%40eu-central-1.amazonses.com.


Re: [Django] #11293: Filters on aggregates lose connector

2022-03-05 Thread Django
#11293: Filters on aggregates lose connector
-+-
 Reporter:  django@… |Owner:  -
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  having, where,   | Triage Stage:  Accepted
  aggregate, connector, annotate |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by GitHub ):

 In [changeset:"a46bc327e70f81b66800780edf3830f6137a89e3" a46bc32]:
 {{{
 #!CommitTicketReference repository=""
 revision="a46bc327e70f81b66800780edf3830f6137a89e3"
 Refs #11293 -- Added test for filtering aggregates with negated &
 operator.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107017f59d57cc0-eadcf809-088d-4efb-8418-6fbb2d32e636-00%40eu-central-1.amazonses.com.


Re: [Django] #33547: Admin TabularInline with readonly field fail to render on validation error

2022-03-05 Thread Django
#33547: Admin TabularInline with readonly field fail to render on validation 
error
-+-
 Reporter:  David Glenck |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  4.0
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  tabularinline| Triage Stage:  Ready for
  readonly   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"445b075def2c037b971518963b70ce13df5e88a2" 445b075d]:
 {{{
 #!CommitTicketReference repository=""
 revision="445b075def2c037b971518963b70ce13df5e88a2"
 Fixed #33547 -- Fixed error when rendering invalid inlines with readonly
 fields in admin.

 Regression in de95c826673be9ea519acc86fd898631d1a11356.

 Thanks David Glenck for the report.
 }}}

-- 
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/0107017f59d5848a-8b86c072-fac5-4f68-82a6-46ee7fdd6d82-00%40eu-central-1.amazonses.com.


Re: [Django] #31255: Migrations create a redundant RemoveField operation when deleting 2 models with related fields.

2022-03-05 Thread Django
#31255: Migrations create a redundant RemoveField operation when deleting 2 
models
with related fields.
--+
 Reporter:  Panagis Alisandratos  |Owner:  (none)
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  Version:  dev
 Severity:  Normal|   Resolution:
 Keywords:  migration,optimizer   | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Mariusz Felisiak):

 * owner:  Simon Charette => (none)
 * status:  assigned => new


-- 
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/0107017f59d574db-7b59521f-34aa-4628-b667-531dda7f19ef-00%40eu-central-1.amazonses.com.


Re: [Django] #28215: sensitive_post_parameters/sensitive_variables leaking sensitive values into the http 500 exception email

2022-03-05 Thread Django
#28215: sensitive_post_parameters/sensitive_variables leaking sensitive values 
into
the http 500 exception email
-+
 Reporter:  Peter Zsoldos|Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Error reporting  |  Version:  1.8
 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 Collin Anderson):

 Simple PR for `password` variables in `django/contrib/auth/forms.py`:
 https://github.com/django/django/pull/15482

-- 
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/0107017f59d56530-94c1bbff-d34d-418b-b373-7f4819ad0abb-00%40eu-central-1.amazonses.com.


Re: [Django] #33555: Enable Model Field choices to hold other Model objects as values of the iterable.

2022-03-05 Thread Django
#33555: Enable Model Field choices to hold other Model objects as values of the
iterable.
-+-
 Reporter:  Mike Okoth   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  choices option for   | Triage Stage:
  model objects  |  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:   => wontfix


Comment:

 Thanks for this proposition, however it's really niche and probably not
 feasible, even if it's feasible I don't think there would be consensus to
 add that complexity. You can raise the idea on the DevelopersMailingList
 to reach a wider audience and see what other think.

-- 
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/0107017f59d5558a-1a273ff8-ff25-4da7-bf45-56330c9aa4d7-00%40eu-central-1.amazonses.com.


Re: [Django] #31169: Allow parallel test runner to work with Windows/macOS `spawn` process start method.

2022-03-05 Thread Django
#31169: Allow parallel test runner to work with Windows/macOS `spawn` process 
start
method.
-+-
 Reporter:  Brandon Navra|Owner:  David
 |  Smith
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107017f59d55d58-361f7625-137e-4e71-be10-2aa955162ca4-00%40eu-central-1.amazonses.com.


Re: [Django] #33555: Enable Model Field choices to hold other Model objects as values of the iterable.

2022-03-05 Thread Django
#33555: Enable Model Field choices to hold other Model objects as values of the
iterable.
-+-
 Reporter:  myk4040okothogodo|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  choices option for   | Triage Stage:
  model objects  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by myk4040okothogodo:

Old description:

> Allow for something like:
> from django.db import models
> from django.utils.translation import ugettext_lazy as _
> from  Documents.models import Document
> from Comments.models import Comment
>
> class Notification(models.Model):
> ENTITY = (
> (Document ,   _('Notification on Document')),
> (Comment ,_('Notification on Comment')),
> )
>
> notificationBelongsTo = models.OneToOneField(choices=ENTITY,default=
> Document,  on_delete=Models.CASCADE)
>
> This would allow for an option to choose the relation from a list of
> objects(that are in this case related models)

New description:

 **Allow for something like:**


 {{{
 from django.db import models
 from django.utils.translation import ugettext_lazy as _
 from  Documents.models import Document
 from Comments.models import Comment

 class Notification(models.Model):
 ENTITY = (
 (Document ,   _('Notification on Document')),
 (Comment ,_('Notification on Comment')),
 )

 notificationBelongsTo = models.OneToOneField(choices=ENTITY,default=
 Document,  on_delete=Models.CASCADE)
 }}}


 This would allow for an option to choose the relation from a list of
 objects(that are in this case related models)

--

-- 
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/0107017f59d54dad-9380a75d-6758-442c-b404-e334ad92cd6d-00%40eu-central-1.amazonses.com.


Re: [Django] #10188: HttpResponse does not filter CR/LF characters from headers

2022-03-05 Thread Django
#10188: HttpResponse does not filter CR/LF characters from headers
-+-
 Reporter:  Bob Thomas   |Owner:
 |  rokclimb15
 Type:   |   Status:  closed
Component:  HTTP handling|  Version:  1.0
 Severity:   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

 * ui_ux:   => 0
 * easy:   => 0


Comment:

 In [changeset:"9bde906fb2b8f63f056284347c660a3fec92ef34" 9bde906]:
 {{{
 #!CommitTicketReference repository=""
 revision="9bde906fb2b8f63f056284347c660a3fec92ef34"
 Refs #10188 -- Added tests for BadHeaderErrors when HTTP header with
 newlines cannot be encoded/decoded.
 }}}

-- 
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/0107017f59d545cc-991249ca-508e-4caf-ba5d-333529240795-00%40eu-central-1.amazonses.com.


Re: [Django] #6135: Introduce a short-cut for template filters that has needs_autoescape = True

2022-03-05 Thread Django
#6135: Introduce a short-cut for template filters that has needs_autoescape = 
True
-+
 Reporter:  anonymous|Owner:  Chinmoy
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  autoescape   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+

Comment (by Mariusz Felisiak):

 > I think we should `wontfix` this.

 Agreed.

-- 
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/0107017f59d53e2d-61504606-4226-48d4-9dd6-c97518e77b24-00%40eu-central-1.amazonses.com.


Re: [Django] #33547: Admin TabularInline with readonly field fail to render on validation error

2022-03-05 Thread Django
#33547: Admin TabularInline with readonly field fail to render on validation 
error
-+-
 Reporter:  David Glenck |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  4.0
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  tabularinline| Triage Stage:  Ready for
  readonly   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Antoine Humbert):

 May be a bit late now, but I think the original reason for this kind of
 bug is because of API inconsistency between AdminReadonlyField and
 AdminField where .field attribute is a dict (with keys) for the former and
 a BoundField (with attributes) for the latter.
 The difference works as soon as it is used in templates because object
 attributes and dict keys are accessed using the same syntax. But as soon
 as it is used in python code (like in reported bug), it breaks. Making
 .field a namedtuple or a dataclass in AdminReadonlyField would have solve
 the problem (without hurting usage in templates) without requiring some
 exceptions management, and would also make things easier to manage if
 .field is used somewhere else in python code.

 What do you think about this ?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107017f59d52e69-491b9627-0c47-4252-8524-1f2e3ad49190-00%40eu-central-1.amazonses.com.


[Django] #33562: set_cookie and set_signed_cookie should accept timedelta object for max_age argument

2022-03-05 Thread Django
#33562: set_cookie and set_signed_cookie should accept timedelta object for 
max_age
argument
-+
   Reporter:  Luke Plant |  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  HTTP handling  |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  |
-+
 This already works for `get_signed_cookie`:
 {{{#!python
 >>> request.get_signed_cookie("mykey", max_age=timedelta(days=3))
 }}}

 This is due to the underlying behaviour of `TimestampSigner`, which was
 fixed to do this in #21363.

 But for `set_cookie` and `set_signed_cookie` it accepts only a number:

 {{{#!python
 >>> response = HttpResponse()
 >>> response.set_cookie("mykey", max_age=timedelta(days=3))
 TypeError: int() argument must be a string, a bytes-like object or a
 number, not 'datetime.timedelta'
 }}}

-- 
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/0107017f59d51ec6-db17abb6-df07-4f17-8887-260fd7f48f74-00%40eu-central-1.amazonses.com.


Re: [Django] #32519: Add support for using key and path transforms in update() for JSONFields.

2022-03-05 Thread Django
#32519: Add support for using key and path transforms in update() for 
JSONFields.
-+-
 Reporter:  Baptiste Mispelon|Owner:  (none)
 Type:  New feature  |   Status:  new
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
-+-
Changes (by allen-munsch):

 * owner:  allen-munsch => (none)
 * status:  assigned => new


-- 
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/0107017f59d516eb-eb707629-e228-49d8-818d-9b7ca3c528fa-00%40eu-central-1.amazonses.com.


Re: [Django] #33524: ModelAdmin with defined radio_fields override empty_label

2022-03-05 Thread Django
#33524: ModelAdmin with defined radio_fields override empty_label
-+-
 Reporter:  Maxim Danilov|Owner:
 |  Hrushikesh Vaidya
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  modeladmin,  | Triage Stage:  Ready for
  radio_fields, empty_label  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107017f59d50f26-230840bc-0969-4e20-9519-adf27788af1b-00%40eu-central-1.amazonses.com.


Re: [Django] #33524: ModelAdmin with defined radio_fields override empty_label

2022-03-05 Thread Django
#33524: ModelAdmin with defined radio_fields override empty_label
-+-
 Reporter:  Maxim Danilov|Owner:
 |  Hrushikesh Vaidya
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  4.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  modeladmin,  | Triage Stage:  Ready for
  radio_fields, empty_label  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"119f227aa62885f12cd7dd2558a62148d02adbb4" 119f227]:
 {{{
 #!CommitTicketReference repository=""
 revision="119f227aa62885f12cd7dd2558a62148d02adbb4"
 Fixed #33524 -- Allowed overriding empty_label for ForeignKey in
 ModelAdmin.radio_fields.
 }}}

-- 
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/0107017f59d5073d-716f223d-4fe4-41d7-84e9-627865d404d8-00%40eu-central-1.amazonses.com.


Re: [Django] #33169: Migrations crashes with long identifiers on MySQL (8.0.26 )

2022-03-05 Thread Django
#33169: Migrations crashes with long identifiers on MySQL (8.0.26 )
-+-
 Reporter:  Awais Qureshi|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  3.2
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
  django32,mysql8.0.26   |  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 extra details and a sample project.

 I was able to reproduce this error, however Django is not at fault, it
 seems to be an issue in MySQL itself. Django executes:
 {{{#!sql
 CREATE TABLE
 `ticket_33169_whiteboxstudentsexaminationdatatransferauditionf7bf` (
 `id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,
 `unique_student_enrollment_id` integer UNSIGNED NOT NULL CHECK
 (`unique_student_enrollment_id` >= 0)
 )
 }}}
 (I called my app `ticket_33169`) so
 `ticket_33169_whiteboxstudentsexaminationdatatransferauditionf7bf_chk_1`
 is a internal name generated by MySQL. Surprisingly, MySQL doesn't respect
 its own limitations.

-- 
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/0107017f59d4ff62-592cdfb3-56d2-4ea3-b4a2-04212a51120f-00%40eu-central-1.amazonses.com.


Re: [Django] #24213: RFC 2231 Section 4.1 is not implemented

2022-03-05 Thread Django
#24213: RFC 2231 Section 4.1 is not implemented
---+
 Reporter:  Raúl Cumplido  |Owner:  (none)
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  dev
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Mariusz Felisiak):

 * status:  assigned => new


-- 
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/0107017f59d4f78e-e4c5a96f-9a1a-46ed-bfec-cb63fd637873-00%40eu-central-1.amazonses.com.


Re: [Django] #33558: Abstract model inheriting from typing.Generic[T] causes TypeError

2022-03-05 Thread Django
#33558: Abstract model inheriting from typing.Generic[T] causes TypeError
-+-
 Reporter:  Rob Percival |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 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:

 Duplicate #33174.

-- 
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/0107017f59d4d839-fe70fb1e-88c6-4356-8ee1-f1847d64120f-00%40eu-central-1.amazonses.com.


Re: [Django] #33169: Migrations crashes with long identifiers on MySQL (8.0.26 )

2022-03-05 Thread Django
#33169: Migrations crashes with long identifiers on MySQL (8.0.26 )
-+-
 Reporter:  Awais Qureshi|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  django32,mysql8.0.26   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Awais Qureshi):

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


-- 
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/0107017f59d4e017-6b8a69cc-82a7-485b-989a-90812473-00%40eu-central-1.amazonses.com.


Re: [Django] #31558: Support the use of boolean attribute on properties in the admin.

2022-03-05 Thread Django
#31558: Support the use of boolean attribute on properties in the admin.
+
 Reporter:  Alexandre Poitevin  |Owner:  (none)
 Type:  New feature |   Status:  new
Component:  contrib.admin   |  Version:  dev
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by Mariusz Felisiak):

 * owner:  Alexandre Poitevin => (none)
 * status:  assigned => new


-- 
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/0107017f59d4d071-f5579ecb-58b0-4742-8edb-64082d4affe7-00%40eu-central-1.amazonses.com.


[Django] #33560: Long Term Support date needs clarification

2022-03-05 Thread Django
#33560: Long Term Support date needs clarification
-+
   Reporter:  Doug Harris|  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Documentation  |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 table of end of support dates on the
 [https://www.djangoproject.com/download/ download page] shows only month
 and year for the end of support for future dates. For example, end of
 extended support for Django 2.2 LTS is listed as "April 2022."

 Is there a policy that it's the beginning of the month? the end of the
 month?

 Past support end dates are shown with the day of the month and recent one
 are ''near'' the beginning of the month but not always on the first.

 Please update the documentation to show this.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107017f59d4c8ab-b37185bf-d497-4913-b874-7bb7a0456ce4-00%40eu-central-1.amazonses.com.


Re: [Django] #33562: set_cookie and set_signed_cookie should accept timedelta object for max_age argument

2022-03-05 Thread Django
#33562: set_cookie and set_signed_cookie should accept timedelta object for 
max_age
argument
---+--
 Reporter:  Luke Plant |Owner:  Luke Plant
 Type:  New feature|   Status:  assigned
Component:  HTTP handling  |  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 Claude Paroz):

 * has_patch:  0 => 1
 * version:  4.0 => dev
 * 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/0107017f59d0d405-bbb9ddfa-57f1-44b2-b6ae-ab52e69a06dd-00%40eu-central-1.amazonses.com.


Re: [Django] #33544: Hint to default behavior (Deployment checklist > TEMPLATES)

2022-03-05 Thread Django
#33544: Hint to default behavior (Deployment checklist > TEMPLATES)
-+-
 Reporter:  Samuel Hartmann  |Owner:  Samuel
 Type:   |  Hartmann
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  deployment   | Triage Stage:
  checklist, TEMPLATES, DEBUG,   |  Unreviewed
  documentation, docs|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 Hi Samuel.

 OK, let's accept a clarification on the docs here. Thanks.

 Note there was discussion on [https://github.com/django/django/pull/15140
 PR 15140] following from ticket #25791 to enable the cached template
 loader even in development.
 If you wanted to dig-in there, I'd be happy to input too. (It's on my list
 to investigate...)

 Welcome aboard! ⛵️

-- 
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/0107017f59d0d5c3-2613987b-e17c-45e1-96f2-53620f7ade4c-00%40eu-central-1.amazonses.com.


Re: [Django] #29865: Add logical XOR support to Q() and QuerySet().

2022-03-05 Thread Django
#29865: Add logical XOR support to Q() and QuerySet().
-+-
 Reporter:  Griffith Rees|Owner:  Ryan
 |  Heard
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  xor  | 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:"c6b4d62fa2c7f73b87f6ae7e8cf1d64ee5312dc5" c6b4d62f]:
 {{{
 #!CommitTicketReference repository=""
 revision="c6b4d62fa2c7f73b87f6ae7e8cf1d64ee5312dc5"
 Fixed #29865 -- Added logical XOR support for Q() and querysets.
 }}}

-- 
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/0107017f59d0d368-d6827886-653f-43ad-981a-4a48321856e3-00%40eu-central-1.amazonses.com.


Re: [Django] #33169: Migrations crashes with long identifiers on MySQL (8.0.26 )

2022-03-05 Thread Django
#33169: Migrations crashes with long identifiers on MySQL (8.0.26 )
-+-
 Reporter:  Awais Qureshi|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  3.2
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
  django32,mysql8.0.26   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Awais Qureshi):

 I have created a simple app to reproduce this issue. You can see three
 `github` checks are running and `django30` and `django32` are showing
 error. Since this feature was introduced in `django30`.

 This change is related with Added support for check constraints on MySQL
 8.0.16+.  [https://github.com/django/django/pull/11743]

 Sample project with long table name where `mysql8` and `django` is
 generating internal checks if model has PositiveIntegerField.

 Possible solution:
 In case of `makemigrations` trigger some error with max length or truncate
 the check name.
 In case of upgrading existing project from `mysql57` to `mysql80` show
 some valid error message during `migrate` command.

-- 
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/0107017f59d0d0a8-8f853f54-a674-4800-9c68-70f3fe0e915d-00%40eu-central-1.amazonses.com.


Re: [Django] #33550: Unexpected on_delete behavior in apps that have been removed from INSTALLED_APPS

2022-03-05 Thread Django
#33550: Unexpected on_delete behavior in apps that have been removed from
INSTALLED_APPS
-+-
 Reporter:  Tobias Bengfort  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Documentation|  Version:  4.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  INSTALLED_APPS   | Triage Stage:
  ForeignKey on_delete   |  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 ticket, however I don't see anything unexpected in the
 current behavior. You removed an app from `INSTALLED_APPS` without
 reverting all applied migrations for that app, so tables, relations, etc.
 still exist in the database. There is nothing Django can do automatically
 in this case.

 > There should be a warning about this in the documentation.

 As it stands it is a usage issue. I don't see it as really common enough
 to justify a warning 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/0107017f59d0d1d9-7c4f6c16-e7d0-4128-be7f-d6d678865365-00%40eu-central-1.amazonses.com.


Re: [Django] #33551: default db selected while deleting object even when different db is mentioned in the query.

2022-03-05 Thread Django
#33551: default db selected while deleting object even when different db is
mentioned in the query.
-+-
 Reporter:  Samyak Gaur  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ORM , multi db,  | Triage Stage:
  query, onetoone|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Samyak Gaur:

Old description:

> we have 2 tables, table (Person)1 and table 2(Customer). There is a one-
> to-one relation between them. We are having problem deleting the parent
> object in a multi-db setup because whenever we run the parent.delete
> query django uses default db to get the child object (Note:default db is
> not the same as db being used).
>
> We created a db connection as follows:
> {{{
> db = {
> 'ENGINE': 'django.contrib.gis.db.backends.postgis',
> 'NAME': 'db_name',
> 'USER': 'db_user',
> 'PASSWORD': 'db_password',
> 'HOST': 'db_host',
> 'PORT': '5432'
> }
> connections.databases['new-stage-db'] = db
> }}}
>
> Tried deleting the object using the command:
>
> {{{
> Parent.objects.using('new-stage-db').get(id=1).delete()
> }}}
>
> and
>
> {{{
> p = Parent.objects.using('new-stage-db').get(id=1)
> p.delete(using='new-stage-db')
> }}}
>
> Surprisingly, django selects default db to get child object instead of
> getting it from the db mentioned above, but all the other child objects
> of this child objects are fetched using the new-stage-db.
>
> Attaching logs for better understanding:
>

> {{{
> In [1]: from django.db import connections
>
> In [2]:
>...: db = {
>...: 'ENGINE': 'django.contrib.gis.db.backends.postgis',
>...: 'NAME': db_name',
>...: 'USER': db_user',
>...: 'PASSWORD':’db_password’,
>...: 'HOST': 'db_host',
>...: 'PORT': '5432'
>...: }
>...: connections.databases['new-stage-db'] = db
>
> In [4]: p = Person.objects.using('new-stage-db').first()
> SELECT "users_person"."id",
>"users_person"."user_id",
>"users_person"."first_name",
>"users_person"."last_name",
>"users_person"."dob",
>"users_person"."gender",
>"users_person"."profile_picture_url",
>"users_person"."searchvectors",
>"users_person"."created",
>"users_person"."modified"
>   FROM "users_person"
>  ORDER BY "users_person"."id" ASC
>  LIMIT 1
>
> Execution time: 0.001734s [Database: new-stage-db]
>
> In [5]: p.customer
> SELECT "users_customer"."id",
>"users_customer"."person_id",
>"users_customer"."email",
>"users_customer"."customers_referral_code",
>"users_customer"."referred_code",
>"users_customer"."eligible_for_referral_bonus",
>"users_customer"."company",
>"users_customer"."created",
>"users_customer"."modified",
>"users_customer"."last_review_requested",
>"users_customer"."status",
>"users_customer"."activity",
>"users_customer"."send_promotional_sms",
>"users_customer"."send_promotional_email",
>"users_customer"."send_applozic_chat_pn",
>"users_customer"."send_vibration_alarm_pn",
>"users_customer"."credits_balance",
>"users_customer"."ghost_credits_balance",
>"users_customer"."otp",
>"users_customer"."otp_refresh_time",
>"users_customer"."city_id",
>"users_customer"."registration_location_id",
>"users_customer"."home_location_id",
>"users_customer"."office_location_id",
>"users_customer"."preferred_profile",
>"users_customer"."office_start_time",
>"users_customer"."office_end_time",
>"users_customer"."seats_preference"
>
> Execution time: 0.001938s [Database: new-stage-db]
> Out[5]: 
>
> In [6]: p.delete()
> SELECT "users_customer"."id"
>   FROM "users_customer"
>  WHERE "users_customer"."person_id" IN (20)
>
> Execution time: 0.000846s [Database: new-stage-db]
> SELECT "users_customer"."id",
>"users_customer"."email"
>   FROM "users_customer"
>  WHERE "users_customer"."id" = 20
>  LIMIT 21
>
> **Execution time: 0.002264s [Database: default]**
> --
> DoesNotExist Traceback (most recent call
> last)
>  in 
> > 1 p.delete()
>
> /usr/local/lib/python3.9/site-packages/django/db/models/base.py in
> delete(self, using, keep_parents)
> 964
>  

Re: [Django] #33553: Use built-in math functions in SQLite 3.35+.

2022-03-05 Thread Django
#33553: Use built-in math functions in SQLite 3.35+.
-+-
 Reporter:  Nick Pope|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  sqlite, math,| Triage Stage:  Ready for
  functions  |  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:"d436554861b9b818994276d7bf110bf03aa565f5" d4365548]:
 {{{
 #!CommitTicketReference repository=""
 revision="d436554861b9b818994276d7bf110bf03aa565f5"
 Fixed #33553 -- Used built-in math functions in SQLite 3.35+.

 In SQLite 3.35+ some math functions are available built-in as long as
 they are not disabled at compile time. We can introspect this and use
 these built-in functions in preference to our slower implementations.
 }}}

-- 
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/0107017f59d0d64d-b1afb314-4d70-403d-a4ac-1fe610b881e2-00%40eu-central-1.amazonses.com.


Re: [Django] #29865: Add logical XOR support to Q() and QuerySet().

2022-03-05 Thread Django
#29865: Add logical XOR support to Q() and QuerySet().
-+-
 Reporter:  Griffith Rees|Owner:  Ryan
 |  Heard
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  xor  | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * stage:  Accepted => Ready for checkin


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107017f59d0d204-97a466e7-b35a-4225-9c00-33a2228368c5-00%40eu-central-1.amazonses.com.


Re: [Django] #31169: Allow parallel test runner to work with Windows/macOS `spawn` process start method.

2022-03-05 Thread Django
#31169: Allow parallel test runner to work with Windows/macOS `spawn` process 
start
method.
---+---
 Reporter:  Brandon Navra  |Owner:  David Smith
 Type:  New feature|   Status:  assigned
Component:  Testing framework  |  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
 * stage:  Ready for checkin => 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/0107017f59d0d436-472faf0d-34a5-4a8a-b402-26300ece9191-00%40eu-central-1.amazonses.com.


Re: [Django] #33547: Admin TabularInline with readonly field fail to render on validation error

2022-03-05 Thread Django
#33547: Admin TabularInline with readonly field fail to render on validation 
error
-+-
 Reporter:  David Glenck |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  4.0
 Severity:  Release blocker  |   Resolution:
 Keywords:  tabularinline| Triage Stage:  Ready for
  readonly   |  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/0107017f59d0d453-6603e219-2bb0-4ee6-8897-4a98f23dfebc-00%40eu-central-1.amazonses.com.


Re: [Django] #33561: Synchronize user attributes on every authentication with RemoteUserBackend

2022-03-05 Thread Django
#33561: Synchronize user attributes on every authentication with 
RemoteUserBackend
-+-
 Reporter:  Adrian Torres|Owner:  Adrian
 |  Torres
 Type:  New feature  |   Status:  assigned
Component:  contrib.auth |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  RemoteUserBackend| Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Adrian Torres):

 * 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/0107017f59d0d53f-b593b598-43c6-49ce-bf2d-4be62b8da5fd-00%40eu-central-1.amazonses.com.


Re: [Django] #33552: SQLite JSONField() doesn't handle numerical has_key lookups

2022-03-05 Thread Django
#33552: SQLite JSONField() doesn't handle numerical has_key lookups
-+-
 Reporter:  TheTerrasque |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 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:

 Duplicate of #30566, see
 [https://code.djangoproject.com/ticket/30566#comment:1 comment].

-- 
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/0107017f59d0d58e-2c68d54d-8b71-4726-8e73-02de295267e9-00%40eu-central-1.amazonses.com.


Re: [Django] #33556: Django Error Connecting to Postgres DB on Docker

2022-03-05 Thread Django
#33556: Django Error Connecting to Postgres DB on Docker
-+-
 Reporter:  Adebayo Osinulu  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.0
  (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 Tim Graham):

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


Comment:

 Django 4.0 [https://docs.djangoproject.com/en/stable/releases/4.0
 /#dropped-support-for-postgresql-9-6 dropped support for  PostgreSQL 9.6].
 Django 4.1+ will give a more helpful error message when using an
 unsupported database version (#33379).

-- 
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/0107017f59d0d61c-a4712585-77c5-4a5a-9bef-80bf05ed6f68-00%40eu-central-1.amazonses.com.


Re: [Django] #33544: Hint to default behavior (Deployment checklist > TEMPLATES)

2022-03-05 Thread Django
#33544: Hint to default behavior (Deployment checklist > TEMPLATES)
-+-
 Reporter:  Samuel Hartmann  |Owner:  Samuel
 Type:   |  Hartmann
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  deployment   | Triage Stage:  Accepted
  checklist, TEMPLATES, DEBUG,   |
  documentation, docs|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * has_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/0107017f59d0d450-b0022f7d-c74d-41cb-821f-7c3e7d6d1a39-00%40eu-central-1.amazonses.com.


Re: [Django] #33553: Use built-in math functions in SQLite 3.35+.

2022-03-05 Thread Django
#33553: Use built-in math functions in SQLite 3.35+.
-+-
 Reporter:  Nick Pope|Owner:  nobody
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite, math,| Triage Stage:  Accepted
  functions  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * 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/0107017f59d0d44c-0abb62ba-513c-4a75-8a9b-6204ba1588bc-00%40eu-central-1.amazonses.com.


Re: [Django] #33551: default db selected while deleting object even when different db is mentioned in the query.

2022-03-05 Thread Django
#33551: default db selected while deleting object even when different db is
mentioned in the query.
-+-
 Reporter:  Samyak Gaur  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  ORM , multi db,  | Triage Stage:
  query, onetoone|  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:   => needsinfo


Comment:

 Thanks for the ticket, however I cannot reproduce your issue. Can you
 provide a sample project showing a fault in Django? Can you reproduce your
 issue with Django 4.0+ or on the current `main` branch?

-- 
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/0107017f59d0d2ca-569b14d7-7a04-41a7-96e8-2dd9a4d762ba-00%40eu-central-1.amazonses.com.


Re: [Django] #33546: Optimise creation of HttpResponseBase and ResponseHeaders objects

2022-03-05 Thread Django
#33546: Optimise creation of HttpResponseBase and ResponseHeaders objects
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  Cleanup/optimization   |   Status:  assigned
Component:  HTTP handling|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"4b2f6ace5789768a5734b017b70b3dec31bb000c" 4b2f6ace]:
 {{{
 #!CommitTicketReference repository=""
 revision="4b2f6ace5789768a5734b017b70b3dec31bb000c"
 Refs #33546 -- Optimized HttpResponseBase.charset a bit.

 This avoids scanning the Content-Type if it's empty, allowing the
 Content-Type header itself to have a charset assigned without using
 the re module.
 }}}

-- 
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/0107017f59d0d6b8-3e2f2319-90b2-4972-9d40-a5917b289cbb-00%40eu-central-1.amazonses.com.


Re: [Django] #33546: Optimise creation of HttpResponseBase and ResponseHeaders objects

2022-03-05 Thread Django
#33546: Optimise creation of HttpResponseBase and ResponseHeaders objects
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  Cleanup/optimization   |   Status:  assigned
Component:  HTTP handling|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"51f896fe25d0593abad2b3c55fd510c46ef57f05" 51f896fe]:
 {{{
 #!CommitTicketReference repository=""
 revision="51f896fe25d0593abad2b3c55fd510c46ef57f05"
 Refs #33546 -- Optimized ResponseHeaders._convert_to_charset() by reducing
 the type-checking duplication.

 In the common case, where keys and values are be encoded into
 ascii/latin-1, defer the checking for newlines until it's been
 successfully coerced to a string.

 Co-authored-by: Nick Pope 
 }}}

-- 
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/0107017f59d0d0bf-a30a8369-d678-45b0-bcb4-fd892e773213-00%40eu-central-1.amazonses.com.


Re: [Django] #33561: Synchronize user attributes on every authentication with RemoteUserBackend

2022-03-05 Thread Django
#33561: Synchronize user attributes on every authentication with 
RemoteUserBackend
-+-
 Reporter:  Adrian Torres|Owner:  Adrian
 |  Torres
 Type:  New feature  |   Status:  closed
Component:  contrib.auth |  Version:  dev
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  RemoteUserBackend| Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Adrian Torres):

 Sure, but in my implementation the synchronization is done right before
 calling `user_can_authenticate` whose output can change due to the
 synchronization.

 Is it really necessary to start a new thread in the mailing list to have
 the patch be reconsidered?

 Cheers,
 Adrian

-- 
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/0107017f59d0d5de-44d05be8-b4bf-4800-b8e4-567b8de51496-00%40eu-central-1.amazonses.com.


[Django] #33553: Use built-in math functions in SQLite 3.35+.

2022-03-05 Thread Django
#33553: Use built-in math functions in SQLite 3.35+.
-+-
   Reporter:  Nick Pope  |  Owner:  nobody
   Type: | Status:  assigned
  Cleanup/optimization   |
  Component:  Database   |Version:  dev
  layer (models, ORM)|   Keywords:  sqlite, math,
   Severity:  Normal |  functions
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 SQLite 3.35+ has support for some built-in math functions. Where they're
 available, we should use them in preference to our own versions as it will
 reduce the number of functions that need to be created for each
 connection. We can check for `ENABLE_MATH_FUNCTIONS` in
 `pragma_compile_options()`.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107017f59d0d3ba-8a771124-0670-4aed-b943-0065d471d99a-00%40eu-central-1.amazonses.com.


[Django] #33561: Synchronize user attributes on every authentication with RemoteUserBackend

2022-03-05 Thread Django
#33561: Synchronize user attributes on every authentication with 
RemoteUserBackend
-+-
   Reporter:  Adrian |  Owner:  Adrian Torres
  Torres |
   Type:  New| Status:  assigned
  feature|
  Component: |Version:  dev
  contrib.auth   |
   Severity:  Normal |   Keywords:  RemoteUserBackend
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 If using a custom RemoteUserBackend, it is possible to want to synchronize
 any changes from the remote system back into the Django user records
 whenever authentication happens.

 Currently, if any user attributes change in the remote system there is no
 easy way to reflect these changes back into the users in the Django
 system.

 The goal of this feature is to introduce a new method in the
 `django.contrib.auth.backends.RemoteUserBackend` class called
 `synchronize_user` with a method signature equal to that of
 `configure_user` (which it complements) that will be called in the
 `authenticate` method of said class right after fetching the user from the
 database (if any), regardless of whether the user was unknown and created
 or otherwise.

 Implementors can then override this method and implement data
 synchronization between the remote user and the Django user that will be
 applied on every user authentication attempt.

-- 
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/0107017f59d0d25c-8365d22f-d66a-439c-999e-569d16b89d84-00%40eu-central-1.amazonses.com.


Re: [Django] #33561: Synchronize user attributes on every authentication with RemoteUserBackend

2022-03-05 Thread Django
#33561: Synchronize user attributes on every authentication with 
RemoteUserBackend
-+-
 Reporter:  Adrian Torres|Owner:  Adrian
 |  Torres
 Type:  New feature  |   Status:  closed
Component:  contrib.auth |  Version:  dev
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  RemoteUserBackend| Triage Stage:
 |  Unreviewed
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:   => wontfix


Comment:

 Thanks for this ticket, however I don't see a strong reason for a new
 hook, you can achieve the same by overriding `authenticate()`, e.g.
 {{{#!python
 class CustomRemoteUserBackend(RemoteUserBackend):
 def authenticate(self, request, remote_user):
 user = super().authenticate(request, remote_user):
 return self.synchronize_user(user)

 def synchronize_user(self, user):
 ...
 }}}

 You can raise the idea on the DevelopersMailingList if you don't agree, to
 reach a wider audience and see what other think (see also
 [https://docs.djangoproject.com/en/stable/internals/contributing/triaging-
 tickets/#closing-tickets  triaging guidelines with regards to wontfix
 tickets]).

-- 
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/0107017f59d0d1d9-b3cfe98c-a463-4765-af4c-2a3538221181-00%40eu-central-1.amazonses.com.


[Django] #33552: SQLite JSONField() doesn't handle numerical has_key lookups

2022-03-05 Thread Django
#33552: SQLite JSONField() doesn't handle numerical has_key lookups
-+-
   Reporter: |  Owner:  nobody
  TheTerrasque   |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  4.0
  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  |
-+-
 == Problem
 When using
 models.[https://docs.djangoproject.com/en/4.0/ref/models/fields/#jsonfield
 JSONField]() [https://docs.djangoproject.com/en/4.0/topics/db/queries
 /#has-key has_key] lookup with numerical keys on SQLite database it fails
 to find the keys.

 == Versions:
   Django: 4.0.3
   Python: 3.9.6 (tags/v3.9.6:db3ff76, Jun 28 2021, 15:26:21) [MSC v.1929
 64 bit (AMD64)] on win32

 == Example:

 === Database


 {{{
 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.sqlite3',
 'NAME': 'db.sqlite3',
 }
 }
 }}}


 === Model


 {{{
 class JsonFieldHasKeyTest(models.Model):
 data = models.JSONField()
 }}}

 === Test

 {{{
 from django.test import TestCase
 from .models import JsonFieldHasKeyTest

 class JsonFieldHasKeyTestCase(TestCase):
 def setUp(self) -> None:
 test = JsonFieldHasKeyTest(data={'foo': 'bar'})
 test2 = JsonFieldHasKeyTest(data={'': 'bar'})
 test.save()
 test2.save()

 def test_json_field_has_key(self):
 c1 =
 JsonFieldHasKeyTest.objects.filter(data__has_key='foo').count()
 c2 =
 JsonFieldHasKeyTest.objects.filter(data__has_key='').count()
 self.assertEqual(c1, 1, "Should have found 1 entry with key
 'foo'")
 self.assertEqual(c2, 1, "Should have found 1 entry with key
 ''")
 }}}

 === Result

 {{{
 FAIL: test_json_field_has_key (markers.tests.JsonFieldHasKeyTestCase)
 --
 Traceback (most recent call last):
   File "H:\Files\Projects\Electaco\Webservice\elecserve\markers\tests.py",
 line 16, in test_json_field_has_key
 self.assertEqual(c2, 1, "Should have found 1 entry with key ''")
 AssertionError: 0 != 1 : Should have found 1 entry with key ''
 }}}

 == Additional info
 This has been tested on SQLite and Postgresql backend, it works on
 postgresql but fails on sqlite.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107017f59d0d5db-057c1bef-1dcc-4d90-90f1-8ae18d4f1773-00%40eu-central-1.amazonses.com.


Re: [Django] #33446: ManifestStaticFilesStorage doesn't update CSS source map references

2022-03-05 Thread Django
#33446: ManifestStaticFilesStorage doesn't update CSS source map references
-+-
 Reporter:  Adam Johnson |Owner:  Adam
 |  Johnson
 Type:  New feature  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  dev
 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:"b811364421c8eea0cf06459462cf1fd58184773b" b8113644]:
 {{{
 #!CommitTicketReference repository=""
 revision="b811364421c8eea0cf06459462cf1fd58184773b"
 Refs #33446 -- Allowed variable whitespace in CSS source map references.

 Follow up to dc8bb35e39388d41b1f38b6c5d0181224e075f16.

 The Webpack default is to output CSS source map comments like
 `/*# sourceMappingURL=main.css.map*/`. Also, Chromium allows tabs.
 }}}

-- 
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/0107017f59d0d6fb-9218b789-57eb-4578-b97a-2aefdfcd09b2-00%40eu-central-1.amazonses.com.


Re: [Django] #6135: Introduce a short-cut for template filters that has needs_autoescape = True

2022-03-05 Thread Django
#6135: Introduce a short-cut for template filters that has needs_autoescape = 
True
-+
 Reporter:  anonymous|Owner:  Chinmoy
 Type:  New feature  |   Status:  closed
Component:  Template system  |  Version:  dev
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  autoescape   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+
Changes (by Carlton Gibson):

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


-- 
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/0107017f59d0d2fb-68eabd71-365a-444c-aefb-703f3af2a08a-00%40eu-central-1.amazonses.com.


[Django] #33556: Django Error Connecting to Postgres DB on Docker

2022-03-05 Thread Django
#33556: Django Error Connecting to Postgres DB on Docker
-+-
   Reporter:  Adebayo|  Owner:  nobody
  Osinulu|
   Type:  Bug| Status:  new
  Component:  Database   |Version:  4.0
  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 started a simple Dockerized django app, however, when I tried to connect
 to the DB (PostgreSQL, also on Docker) I get this error

 {{{

 ERROR:  column c.relispartition does not exist at character 54
 db_1   | STATEMENT:
 db_1   |SELECT c.relname,
 db_1   |CASE WHEN c.relispartition THEN 'p' WHEN
 c.relkind IN ('m', 'v') THEN 'v' ELSE 't' END
 db_1   |FROM pg_catalog.pg_class c
 db_1   |LEFT JOIN pg_catalog.pg_namespace n ON n.oid =
 c.relnamespace
 db_1   |WHERE c.relkind IN ('f', 'm', 'p', 'r', 'v')
 db_1   |AND n.nspname NOT IN ('pg_catalog',
 'pg_toast')
 db_1   |AND pg_catalog.pg_table_is_visible(c.oid)
 db_1   |
 web_1  | Exception in thread django-main-thread:
 web_1  | Traceback (most recent call last):
 web_1  |   File "/usr/local/lib/python3.8/site-
 packages/django/db/backends/utils.py", line 83, in _execute
 web_1  | return self.cursor.execute(sql)
 web_1  | psycopg2.errors.UndefinedColumn: column c.relispartition does not
 exist
 web_1  | LINE 3: CASE WHEN c.relispartition THEN 'p' WHEN
 c.relki...
 web_1  |   ^
 web_1  |
 web_1  |
 web_1  | The above exception was the direct cause of the following
 exception:
 web_1  |
 web_1  | Traceback (most recent call last):
 web_1  |   File "/usr/local/lib/python3.8/threading.py", line 932, in
 _bootstrap_inner
 web_1  | self.run()
 web_1  |   File "/usr/local/lib/python3.8/threading.py", line 870, in run
 web_1  | self._target(*self._args, **self._kwargs)
 web_1  |   File "/usr/local/lib/python3.8/site-
 packages/django/utils/autoreload.py", line 64, in wrapper
 web_1  | fn(*args, **kwargs)
 web_1  |   File "/usr/local/lib/python3.8/site-
 packages/channels/management/commands/runserver.py", line 76, in inner_run
 web_1  | self.check_migrations()
 web_1  |   File "/usr/local/lib/python3.8/site-
 packages/django/core/management/base.py", line 505, in check_migrations
 web_1  | executor = MigrationExecutor(connections[DEFAULT_DB_ALIAS])
 web_1  |   File "/usr/local/lib/python3.8/site-
 packages/django/db/migrations/executor.py", line 18, in __init__
 web_1  | self.loader = MigrationLoader(self.connection)
 web_1  |   File "/usr/local/lib/python3.8/site-
 packages/django/db/migrations/loader.py", line 53, in __init__
 web_1  | self.build_graph()
 web_1  |   File "/usr/local/lib/python3.8/site-
 packages/django/db/migrations/loader.py", line 223, in build_graph
 web_1  | self.applied_migrations = recorder.applied_migrations()
 web_1  |   File "/usr/local/lib/python3.8/site-
 packages/django/db/migrations/recorder.py", line 77, in applied_migrations
 web_1  | if self.has_table():
 web_1  |   File "/usr/local/lib/python3.8/site-
 packages/django/db/migrations/recorder.py", line 56, in has_table
 web_1  | tables = self.connection.introspection.table_names(cursor)
 web_1  |   File "/usr/local/lib/python3.8/site-
 packages/django/db/backends/base/introspection.py", line 52, in
 table_names
 web_1  | return get_names(cursor)
 web_1  |   File "/usr/local/lib/python3.8/site-
 packages/django/db/backends/base/introspection.py", line 47, in get_names
 web_1  | return sorted(ti.name for ti in self.get_table_list(cursor)
 web_1  |   File "/usr/local/lib/python3.8/site-
 packages/django/db/backends/postgresql/introspection.py", line 49, in
 get_table_list
 web_1  | cursor.execute("""
 web_1  |   File "/usr/local/lib/python3.8/site-
 packages/django/db/backends/utils.py", line 99, in execute
 web_1  | return super().execute(sql, params)
 web_1  |   File "/usr/local/lib/python3.8/site-
 packages/django/db/backends/utils.py", line 67, in execute
 web_1  | return self._execute_with_wrappers(sql, params, many=False,
 executor=self._execute)
 web_1  |   File "/usr/local/lib/python3.8/site-
 packages/django/db/backends/utils.py", line 76, in _execute_with_wrappers
 web_1  | return executor(sql, params, many, context)
 web_1  |   File "/usr/local/lib/python3.8/site-
 packages/django/db/backends/utils.py", line 85, in _execute
 web_1  | return 

Re: [Django] #16406: Allow separate access to matches from urlpatterns and extra_context args

2022-03-05 Thread Django
#16406: Allow separate access to matches from urlpatterns and extra_context args
-+-
 Reporter:  Florian Apolloner|Owner:  Alokik
 Type:   |  Roy
  Cleanup/optimization   |   Status:  assigned
Component:  Core (URLs)  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  resolvers, reverse   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Alokik Roy):

 * cc: Alokik Roy (added)


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107017f59d0d43c-83b4d8b0-eac1-4247-bc71-3f72095a43ff-00%40eu-central-1.amazonses.com.


[Django] #33559: Django Admin Site - add filter for group's chosen permissions

2022-03-05 Thread Django
#33559: Django Admin Site - add filter for group's chosen permissions
-+-
   Reporter:  Victor |  Owner:  nobody
  Mion   |
   Type:  New| Status:  new
  feature|
  Component: |Version:  4.0
  contrib.admin  |   Keywords:  admin chosen
   Severity:  Normal |  permissions filter
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 A project I work with has a lot of models and thus a lot of permissions.
 It would be helpful being able to filter a group's chosen permissions in
 the django admin site.
 Adding a filter field working precisely the same as the filter under a
 group's available permissions would be great.

-- 
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/0107017f59d0d4f3-df269a02-d874-49a8-86ca-f68d53b63818-00%40eu-central-1.amazonses.com.


Re: [Django] #32619: 'ManyToOneRel' object has no attribute 'get_limit_choices_to'

2022-03-05 Thread Django
#32619: 'ManyToOneRel' object has no attribute 'get_limit_choices_to'
---+--
 Reporter:  Seb G  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  3.2
 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 benedicthsieh):

 Replying to [comment:8 Timothy Allen]:
 > For anyone who finds this ticket with the same error: this error will be
 triggered if you are using the third party Django admin packages `django-
 admin-autocomplete-filter` or `django-admin-rangefilter`. Upgrade to the
 latest versions (as of this writing, `django-admin-rangefilter==0.6.3` and
 `django-admin-autocomplete-filter==0.8.3`) and it should resolve the
 error.

 I wasn't able to find version 0.8.3 of django-admin-autocomplete-filter,
 do you have a source? https://github.com/farhan0581/django-admin-
 autocomplete-filter/releases only goes up to 0.7.1, which is still broken.
 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/0107017f59d0d0b1-c48ef8cb-8079-4d15-80d3-3990f9951667-00%40eu-central-1.amazonses.com.


Re: [Django] #30032: Allow expressions to be used for default

2022-03-05 Thread Django
#30032: Allow expressions to be used for default
-+-
 Reporter:  Gavin Wahl   |Owner:  Johannes
 |  Maron
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 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/0107017f59d0d494-02cd0430-02ca-4ef3-896f-bb639b1101c7-00%40eu-central-1.amazonses.com.


Re: [Django] #27624: Optimize ORM by using more immutable data structures

2022-03-05 Thread Django
#27624: Optimize ORM by using more immutable data structures
-+-
 Reporter:  Adam Johnson |Owner:  Adam
 Type:   |  Johnson
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  1.10
  (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 Mariusz Felisiak ):

 In [changeset:"6d5709ce7dc37999a4d12c3ecf2a661afe097b2a" 6d5709ce]:
 {{{
 #!CommitTicketReference repository=""
 revision="6d5709ce7dc37999a4d12c3ecf2a661afe097b2a"
 Refs #27624 -- Optimized sql.Query creation by moving immutable/singleton
 attributes to class attributes.
 }}}

-- 
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/0107017f59d0d54c-91bdc15b-e089-4aa0-9983-e77fa218ecf6-00%40eu-central-1.amazonses.com.


Re: [Django] #6135: Introduce a short-cut for template filters that has needs_autoescape = True

2022-03-05 Thread Django
#6135: Introduce a short-cut for template filters that has needs_autoescape = 
True
-+
 Reporter:  anonymous|Owner:  Chinmoy
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  autoescape   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+

Comment (by Carlton Gibson):

 I think we should `wontfix` this. Copying my
 [https://github.com/django/django/pull/14784#pullrequestreview-898610549
 comment from the PR]:

 > I have to say that after 14 years I think we should probably close this
 as wontfix. 
 >
 > I think the new decorator is likely to cause more confusion that it'll
 solve.
 >
 > Specifically, it's only going to be appropriate for filters already
 marked @stringfilter — that's fine, in theory, but that's not documented
 at all — and it's going to be anything but clear to document — and we're
 going to see a whole load of reports saying @autoescape_aware doesn't work
 with my filter.
 >
 > There's already a way to do this, and the proposed decorator isn't
 sufficiently robust to cover all cases.
 >
 > Also, as evidenced by those 14 years, I'm not convinced the saving is
 all that great:
 >
 > if autoescape:
 > esc = conditional_escape
 > else:
 > esc = lambda x: x
 > … OK, yes. It's slightly repetitive. If it really bothered me I could
 write a make_escape() factory function to remove the duplication. But, on
 the other hand, it's clear: there's no question of what the behaviour is,
 and I don't have to go looking into the source to see how the parameters
 get applied.
 >
 > Summary, I'm not at all convinced the proposed decorator pays its way.
 > 樂

-- 
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/0107017f59d0d3df-3b321e06-67f6-4542-90a0-8d0fd50248e0-00%40eu-central-1.amazonses.com.


Re: [Django] #16406: Allow separate access to matches from urlpatterns and extra_context args

2022-03-05 Thread Django
#16406: Allow separate access to matches from urlpatterns and extra_context args
-+-
 Reporter:  Florian Apolloner|Owner:  Alokik
 Type:   |  Roy
  Cleanup/optimization   |   Status:  assigned
Component:  Core (URLs)  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  resolvers, reverse   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Alokik Roy):

 * needs_better_patch:  1 => 0


Comment:

 Added tests and documentation

-- 
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/0107017f59d0d1f1-e873ef29-ab02-4404-a2d9-2beb2218c478-00%40eu-central-1.amazonses.com.


Re: [Django] #470: Add Field.db_default for defining database defaults

2022-03-05 Thread Django
#470: Add Field.db_default for defining database defaults
-+-
 Reporter:  jws  |Owner:  Ayush
 |  Joshi
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  normal   |   Resolution:
 Keywords:  sql schema   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ayush Joshi):

 * owner:  Ian Foote => Ayush Joshi


-- 
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/0107017f59d0d1bf-4c8a9c21-7ceb-43e4-bb4f-200ff5e416ba-00%40eu-central-1.amazonses.com.


Re: [Django] #33552: has_key, has_keys, and has_any_keys JSONField() lookups don't handle numeric keys on SQLite, MySQL, and Oracle. (was: SQLite JSONField() doesn't handle numerical has_key lookups)

2022-03-05 Thread Django
#33552: has_key, has_keys, and has_any_keys JSONField() lookups don't handle
numeric keys on SQLite, MySQL, and Oracle.
-+-
 Reporter:  TheTerrasque |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.0
  (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
-+-
Changes (by Mariusz Felisiak):

 * cc: Sage Abdullah (added)
 * stage:  Unreviewed => Accepted


Comment:

 I reproduce this issue on SQLite, MySQL, and Oracle. `has_key`,
 `has_keys`, and `has_any_keys` lookups uses `compile_json_path()` on
 SQLite, MySQL, and Oracle which uses array paths for integers. We
 shouldn't use array paths for these lookups.

-- 
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/0107017f59d0d1d9-b4520961-f137-435a-8da6-7c509d30496b-00%40eu-central-1.amazonses.com.


Re: [Django] #33549: Cannot use functools.partial when connecting to a signal handler when DEBUG=False

2022-03-05 Thread Django
#33549: Cannot use functools.partial when connecting to a signal handler when
DEBUG=False
--+--
 Reporter:  Salaah Amin   |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Core (Other)  |  Version:  3.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
--+--
Changes (by Mariusz Felisiak):

 * status:  new => closed
 * resolution:   => needsinfo
 * component:  Uncategorized => Core (Other)


Comment:

 Hi, I don't think you've explained the issue in enough detail to confirm a
 bug in Django. Please reopen the ticket if you can debug your issue and
 provide details about why and where Django is at fault. 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/0107017f59d0d5ea-aa43e68a-e9a2-43b0-b6c7-b9a18a63eda7-00%40eu-central-1.amazonses.com.


Re: [Django] #33561: Synchronize user attributes on every authentication with RemoteUserBackend

2022-03-05 Thread Django
#33561: Synchronize user attributes on every authentication with 
RemoteUserBackend
-+-
 Reporter:  Adrian Torres|Owner:  Adrian
 |  Torres
 Type:  New feature  |   Status:  assigned
Component:  contrib.auth |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  RemoteUserBackend| Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Adrian Torres):

 * owner:  Adrian Torres => Adrian Torres


-- 
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/0107017f59d0d1f7-b3339bdd-df86-488d-8596-e35bd8ad618e-00%40eu-central-1.amazonses.com.


Re: [Django] #24213: RFC 2231 Section 4.1 is not implemented

2022-03-05 Thread Django
#24213: RFC 2231 Section 4.1 is not implemented
---+
 Reporter:  Raúl Cumplido  |Owner:  (none)
 Type:  New feature|   Status:  assigned
Component:  HTTP handling  |  Version:  dev
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Mariusz Felisiak):

 * owner:  Raúl Cumplido => (none)
 * 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/0107017f59d0d4a7-89508587-5899-4e3f-b8e3-4c9edca0ad91-00%40eu-central-1.amazonses.com.


[Django] #33551: default db selected while deleting object even when different db is mentioned in the query.

2022-03-05 Thread Django
#33551: default db selected while deleting object even when different db is
mentioned in the query.
-+-
   Reporter:  Samyak |  Owner:  nobody
  Gaur   |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.2
  layer (models, ORM)|   Keywords:  ORM , multi db,
   Severity:  Normal |  query, onetoone
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 we have 2 tables, table (Person)1 and table 2(Customer). There is a one-
 to-one relation between them. We are having problem deleting the parent
 object in a multi-db setup because whenever we run the parent.delete query
 django uses default db to get the child object (Note:default db is not the
 same as db being used).

 We created a db connection as follows:
 {{{
 db = {
 'ENGINE': 'django.contrib.gis.db.backends.postgis',
 'NAME': 'db_name',
 'USER': 'db_user',
 'PASSWORD': 'db_password',
 'HOST': 'db_host',
 'PORT': '5432'
 }
 connections.databases['new-stage-db'] = db
 }}}

 Tried deleting the object using the command:

 {{{
 Parent.objects.using('new-stage-db').get(id=1).delete()
 }}}

 and

 {{{
 p = Parent.objects.using('new-stage-db').get(id=1)
 p.delete(using='new-stage-db')
 }}}

 Surprisingly, django selects default db to get child object instead of
 getting it from the db mentioned above, but all the other child objects of
 this child objects are fetched using the new-stage-db.

 Attaching logs for better understanding:


 {{{
 In [1]: from django.db import connections

 In [2]:
...: db = {
...: 'ENGINE': 'django.contrib.gis.db.backends.postgis',
...: 'NAME': db_name',
...: 'USER': db_user',
...: 'PASSWORD':’db_password’,
...: 'HOST': 'db_host',
...: 'PORT': '5432'
...: }
...: connections.databases['new-stage-db'] = db

 In [4]: p = Person.objects.using('new-stage-db').first()
 SELECT "users_person"."id",
"users_person"."user_id",
"users_person"."first_name",
"users_person"."last_name",
"users_person"."dob",
"users_person"."gender",
"users_person"."profile_picture_url",
"users_person"."searchvectors",
"users_person"."created",
"users_person"."modified"
   FROM "users_person"
  ORDER BY "users_person"."id" ASC
  LIMIT 1

 Execution time: 0.001734s [Database: new-stage-db]

 In [5]: p.customer
 SELECT "users_customer"."id",
"users_customer"."person_id",
"users_customer"."email",
"users_customer"."customers_referral_code",
"users_customer"."referred_code",
"users_customer"."eligible_for_referral_bonus",
"users_customer"."company",
"users_customer"."created",
"users_customer"."modified",
"users_customer"."last_review_requested",
"users_customer"."status",
"users_customer"."activity",
"users_customer"."send_promotional_sms",
"users_customer"."send_promotional_email",
"users_customer"."send_applozic_chat_pn",
"users_customer"."send_vibration_alarm_pn",
"users_customer"."credits_balance",
"users_customer"."ghost_credits_balance",
"users_customer"."otp",
"users_customer"."otp_refresh_time",
"users_customer"."city_id",
"users_customer"."registration_location_id",
"users_customer"."home_location_id",
"users_customer"."office_location_id",
"users_customer"."preferred_profile",
"users_customer"."office_start_time",
"users_customer"."office_end_time",
"users_customer"."seats_preference"

 Execution time: 0.001938s [Database: new-stage-db]
 Out[5]: 

 In [6]: p.delete()
 SELECT "users_customer"."id"
   FROM "users_customer"
  WHERE "users_customer"."person_id" IN (20)

 Execution time: 0.000846s [Database: new-stage-db]
 SELECT "users_customer"."id",
"users_customer"."email"
   FROM "users_customer"
  WHERE "users_customer"."id" = 20
  LIMIT 21

 **Execution time: 0.002264s [Database: default]**
 --
 DoesNotExist Traceback (most recent call last)
  in 
 > 1 p.delete()

 /usr/local/lib/python3.9/site-packages/django/db/models/base.py in
 delete(self, using, keep_parents)
 964
 965 collector = Collector(using=using)
 --> 966 collector.collect([self], keep_parents=keep_parents)
 967 return collector.delete()
 968

 

Re: [Django] #24481: Improve sqlmigrate to be more flexible and allow bypassing migrations on disk

2022-03-05 Thread Django
#24481: Improve sqlmigrate to be more flexible and allow bypassing migrations on
disk
-+-
 Reporter:  pascal chambon   |Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Core (Management |  Version:  dev
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  migrate migrations   | Triage Stage:  Accepted
  sqlall |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * owner:  Andrew Godwin => (none)
 * status:  assigned => new


-- 
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/0107017f59d0d4e5-fc4db5b5-6831-4a49-9820-4699d238a142-00%40eu-central-1.amazonses.com.


Re: [Django] #26626: Update decorator_from_middleware to work with new-style middleware

2022-03-05 Thread Django
#26626: Update decorator_from_middleware to work with new-style middleware
---+
 Reporter:  Tim Graham |Owner:  (none)
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  dev
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Mariusz Felisiak):

 * owner:  Carl Meyer => (none)
 * status:  assigned => new


-- 
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/0107017f59d0d33b-099c99ef-6bba-4973-ab38-19c69ae997e9-00%40eu-central-1.amazonses.com.


[Django] #33555: Enable Model Field choices to hold other Model objects as values of the iterable.

2022-03-05 Thread Django
#33555: Enable Model Field choices to hold other Model objects as values of the
iterable.
-+-
   Reporter: |  Owner:  nobody
  myk4040okothogodo  |
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  4.0
  layer (models, ORM)|   Keywords:  choices option for
   Severity:  Normal |  model objects
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Allow for something like:
 from django.db import models
 from django.utils.translation import ugettext_lazy as _
 from  Documents.models import Document
 from Comments.models import Comment

 class Notification(models.Model):
 ENTITY = (
 (Document ,   _('Notification on Document')),
 (Comment ,_('Notification on Comment')),
 )

 notificationBelongsTo = models.OneToOneField(choices=ENTITY,default=
 Document,  on_delete=Models.CASCADE)

 This would allow for an option to choose the relation from a list of
 objects(that are in this case related models)

-- 
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/0107017f59d0d47a-831f9bb6-d299-4720-9995-51b791185e52-00%40eu-central-1.amazonses.com.


Re: [Django] #33554: Only first translation being found in Jinja handlebars when multiple strings are defined

2022-03-05 Thread Django
#33554: Only first translation being found in Jinja handlebars when multiple
strings are defined
-+-
 Reporter:  Alex Ford|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Utilities|  Version:  3.2
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  translations,| Triage Stage:
  makemessages, jinja, handlebars,   |  Unreviewed
  multiple strings   |
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:   => duplicate


Comment:

 Looks like this is a duplicate of #24167 — Please follow-up Alex if
 investigation there reveals not.

-- 
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/0107017f59d0d3a5-1a705c48-519f-48a8-a5df-0dc5f75a1906-00%40eu-central-1.amazonses.com.


Re: [Django] #33554: Only first translation being found in Jinja handlebars when multiple strings are defined

2022-03-05 Thread Django
#33554: Only first translation being found in Jinja handlebars when multiple
strings are defined
-+-
 Reporter:  Alex Ford|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Utilities|  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  translations,| Triage Stage:
  makemessages, jinja, handlebars,   |  Unreviewed
  multiple strings   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 Hi Alex. Hmmm...

 So, question, why is this not an issue for Jinga? (Or, equally, what could
 Django do about this?) 樂

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107017f59d0d3e2-cab868dd-01ca-433c-a24d-ceb4fb24e88d-00%40eu-central-1.amazonses.com.


Re: [Django] #33546: Optimise creation of HttpResponseBase and ResponseHeaders objects

2022-03-05 Thread Django
#33546: Optimise creation of HttpResponseBase and ResponseHeaders objects
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  Cleanup/optimization   |   Status:  closed
Component:  HTTP handling|  Version:  dev
 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


-- 
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/0107017f59d0d157-507ca1b7-0f3f-4655-8884-c182f004d8c6-00%40eu-central-1.amazonses.com.


Re: [Django] #33553: Use built-in math functions in SQLite 3.35+.

2022-03-05 Thread Django
#33553: Use built-in math functions in SQLite 3.35+.
-+-
 Reporter:  Nick Pope|Owner:  nobody
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite, math,| Triage Stage:
  functions  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Nick Pope):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/15473 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/0107017f59d0cf7b-6064cc1f-66ca-40e1-a4fa-2dc73dcefa79-00%40eu-central-1.amazonses.com.


Re: [Django] #33560: Long Term Support date needs clarification

2022-03-05 Thread Django
#33560: Long Term Support date needs clarification
---+--
 Reporter:  Doug Harris|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  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 Tim Graham):

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


Comment:

 The exact date isn't determined until the time comes. It's usually been at
 the beginning of the month when a series of releases are ready (possibly
 including one last release of the expiring version).

 For future reference, the bug tracker for www.djangoproject.com is at
 https://github.com/django/djangoproject.com/issues.

-- 
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/0107017f59d0d3cd-091bb3c9-ab51-4abd-967b-fefb85ab6580-00%40eu-central-1.amazonses.com.


[Django] #33554: Only first translation being found in Jinja handlebars when multiple strings are defined

2022-03-05 Thread Django
#33554: Only first translation being found in Jinja handlebars when multiple
strings are defined
-+-
   Reporter:  Alex Ford  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Utilities  |Version:  3.2
   Severity:  Normal |   Keywords:  translations,
 |  makemessages, jinja, handlebars,
   Triage Stage: |  multiple strings
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When running makemessages on our project we found some strings were
 missing from translations in our Jinja files. After diving into
 ''utils/translation/template.py'' we found examples of where the
 translations were going wrong.

 Below is an example of it working:

 `{{ _('Hello World') }}` - This works fine and `'Hello World'` is added to
 the translatable strings. This example has a token type VAR.


 Below are 3 examples of it not working:

 `{{ _('Hello World') + _('Foobar') }}` - `'Hello World'` is added to the
 translatable strings but `'Foobar'` is not. This example has a token type
 VAR. Seems to be only trying to find one word to match with and that's it,
 should be finding all possible words.

 `{{ foo(_('Hello World'), _('Foobar')) }}` - Exact same as above example.
 This is our common use case of this bug.

 {{{
 {{ _('Hello World') +
_('Foobar') }}
 }}}
 This example is a bit different as this doesn't find any of the words as
 this is seen as a token type TEXT which gets ignored.

-- 
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/0107017f59d0d3e5-bf75171f-0151-42df-9a25-765c245be7b6-00%40eu-central-1.amazonses.com.


Re: [Django] #33546: Optimise creation of HttpResponseBase and ResponseHeaders objects

2022-03-05 Thread Django
#33546: Optimise creation of HttpResponseBase and ResponseHeaders objects
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  Cleanup/optimization   |   Status:  assigned
Component:  HTTP handling|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"95b7d01d3856da323a610338aaa6882e82e4cc48" 95b7d01d]:
 {{{
 #!CommitTicketReference repository=""
 revision="95b7d01d3856da323a610338aaa6882e82e4cc48"
 Refs #33546 -- Optimized handling content types in
 HttpResponseBase.__init__().

 This removes an extraneous conditional causing "Content-Type" to be
 checked within the ResponseHeaders twice, if a content_type parameter
 is provided.
 }}}

-- 
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/0107017f59d0d517-0d321069-ed82-4c53-aa92-dcaa1ed76b1f-00%40eu-central-1.amazonses.com.


[Django] #33557: Traversing a reverse Generic Foreign Key

2022-03-05 Thread Django
#33557: Traversing a reverse Generic Foreign Key
-+
   Reporter:  rymanso|  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  Uncategorized  |Version:  4.0
   Severity:  Normal |   Keywords:  QuerySet.extra
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 Traversing a reverse Generic Foreign Key.
 When we initially designed our system we created a model with a Generic
 Foreign Key as opposed to Generic Relations on all models.
 As Django doesn't support traversing a reverse generic foreign key
 relationship, we can do so using an "extra" query.
 If discontinued we will have to make larger changes to our system.

-- 
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/0107017f59d0d207-d116db62-8350-4013-bdb4-e1984a766143-00%40eu-central-1.amazonses.com.


Re: [Django] #10874: ModelFormMetaclass does not provide easy way of extending

2022-03-05 Thread Django
#10874: ModelFormMetaclass does not provide easy way of extending
-+
 Reporter:  wombat   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  1.0
 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 Matt Westcott):

 For anyone looking for a way to extend ModelFormOptions with their own
 options, I found this recipe works well: https://github.com/wagtail
 /django-permissionedforms/blob/main/permissionedforms/forms.py

 There's a slight bit of ugliness in the implementation, in that
 ModelFormMetaclass builds a ModelFormOptions instance to do its own thing,
 which then gets thrown away and replaced with the custom ModelFormOptions
 subclass, meaning that the ModelFormOptions constructor ends up running
 for a second time. This could be avoided if ModelFormMetaclass were to
 look for an `options_class` attribute on either the target class (as per
 above) or itself (as per my implementation).

 (Even better, Django could move the 'collect options from an inner Meta
 class' logic into a mixin as I've done, so that the pattern of having
 various form mixin classes contribute their own options can happen with or
 without ModelForm. But given the lack of activity on this issue, that's
 probably too niche an interest to be worth the disruption :-) )

-- 
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/0107017f59d0d0ad-f0a24251-8835-401f-8e0d-1f57a0c2f9bb-00%40eu-central-1.amazonses.com.


Re: [Django] #33544: Hint to default behavior (Deployment checklist > TEMPLATES)

2022-03-05 Thread Django
#33544: Hint to default behavior (Deployment checklist > TEMPLATES)
-+-
 Reporter:  Samuel Hartmann  |Owner:  Samuel
 Type:   |  Hartmann
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  deployment   | Triage Stage:  Accepted
  checklist, TEMPLATES, DEBUG,   |
  documentation, docs|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * 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/0107017f59d0d26d-ece10b28-07cb-42d1-963c-fafe33be2bb8-00%40eu-central-1.amazonses.com.


Re: [Django] #33557: Traversing a reverse Generic Foreign Key

2022-03-05 Thread Django
#33557: Traversing a reverse Generic Foreign Key
-+-
 Reporter:  rymanso  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  QuerySet.extra   | 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:   => needsinfo
 * component:  Uncategorized => Database layer (models, ORM)


Comment:

 Thanks for the ticket, however
 [https://docs.djangoproject.com/en/stable/ref/contrib/contenttypes
 /#reverse-generic-relations reverse generic relations] can be handled with
 `GenericRelation()`. I'm not sure what exact feature you are requesting.

 [https://docs.djangoproject.com/en/4.0/internals/contributing/bugs-and-
 features/#requesting-features Please follow triaging guidelines with
 regards to new features] and describe clearly and concisely what the
 missing feature is.

-- 
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/0107017f59d0d274-34b315d3-96b0-4adc-8846-4408ab9f401d-00%40eu-central-1.amazonses.com.


Re: [Django] #33546: Optimise creation of HttpResponseBase and ResponseHeaders objects

2022-03-05 Thread Django
#33546: Optimise creation of HttpResponseBase and ResponseHeaders objects
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  Cleanup/optimization   |   Status:  assigned
Component:  HTTP handling|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"e0b197c63c7e11352305bc9d8a408309e67dcea6" e0b197c]:
 {{{
 #!CommitTicketReference repository=""
 revision="e0b197c63c7e11352305bc9d8a408309e67dcea6"
 Refs #33546 -- Avoided unpacking data in ResponseHeaders when not
 necessary.
 }}}

-- 
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/0107017f59d0d2d3-615dad93-e64c-46b2-a5a0-629ccd203fd2-00%40eu-central-1.amazonses.com.


Re: [Django] #33546: Optimise creation of HttpResponseBase and ResponseHeaders objects

2022-03-05 Thread Django
#33546: Optimise creation of HttpResponseBase and ResponseHeaders objects
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  Cleanup/optimization   |   Status:  assigned
Component:  HTTP handling|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * 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/0107017f59d0cfca-c0de9994-7ddb-440f-ace3-2764cd8c281e-00%40eu-central-1.amazonses.com.


Re: [Django] #31949: Allow builtin view decorators to be applied directly to async views.

2022-03-05 Thread Django
#31949: Allow builtin view decorators to be applied directly to async views.
+-
 Reporter:  Michael Galler  |Owner:  Ben Lomax
 Type:  New feature |   Status:  assigned
Component:  Core (Other)|  Version:  3.1
 Severity:  Normal  |   Resolution:
 Keywords:  async   | 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):

 * 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/0107017f59d0d1cc-2b70b9b2-ad5c-456a-a6c3-d8779f09cce9-00%40eu-central-1.amazonses.com.


Re: [Django] #27737: Investigate if reloading old relational fields in migration operations' state_forwards is needed

2022-03-05 Thread Django
#27737: Investigate if reloading old relational fields in migration operations'
state_forwards is needed
--+
 Reporter:  Markus Holtermann |Owner:  (none)
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  Version:  dev
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Mariusz Felisiak):

 * owner:  Markus Holtermann => (none)
 * status:  assigned => new


-- 
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/0107017f59d0d102-282cda11-7e8c-4184-a0cd-e8511dc8df6c-00%40eu-central-1.amazonses.com.


Re: [Django] #33559: Django Admin Site - add filter for group's chosen permissions

2022-03-05 Thread Django
#33559: Django Admin Site - add filter for group's chosen permissions
-+-
 Reporter:  Victor Mion  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  4.0
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  admin chosen | Triage Stage:
  permissions filter |  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:

 Duplicate of #24179.

-- 
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/0107017f59d0d2b1-7d21fc7e-f4b2-42b8-a596-fdfbad4af94b-00%40eu-central-1.amazonses.com.


[Django] #33558: Abstract model inheriting from typing.Generic[T] causes TypeError

2022-03-05 Thread Django
#33558: Abstract model inheriting from typing.Generic[T] causes TypeError
-+-
   Reporter:  Rob|  Owner:  nobody
  Percival   |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  4.0
  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  |
-+-
 The exception message is "**TypeError: Cannot inherit from plain
 Generic**". Example:

 {{{
 T = typing.TypeVar("T")

 class AbstractModel(models.Model, Generic[T]):
 foo: T  # Bad example of how you might use a TypeVar

 class Meta:
 abstract = True

 class IntModel(AbstractModel[int]):
 …
 }}}

 A better explanation of the issue and a patch can be found here:
 https://github.com/typeddjango/django-stubs/issues/299

-- 
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/0107017f59d0d335-23f4f6f2-17c7-4784-bd25-1a43cb837e0c-00%40eu-central-1.amazonses.com.


Re: [Django] #33553: Use built-in math functions in SQLite 3.35+.

2022-03-05 Thread Django
#33553: Use built-in math functions in SQLite 3.35+.
-+-
 Reporter:  Nick Pope|Owner:  nobody
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite, math,| Triage Stage:  Ready for
  functions  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * stage:  Accepted => Ready for checkin


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107017f59d0d12a-19eddba0-af5f-41cf-b8d0-b3f28d95cb86-00%40eu-central-1.amazonses.com.


[Django] #33549: Cannot use functools.partial when connecting to a signal handler when DEBUG=False

2022-03-05 Thread Django
#33549: Cannot use functools.partial when connecting to a signal handler when
DEBUG=False
-+
   Reporter:  Salaah Amin|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Uncategorized  |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  |
-+
 Come across an issue where a signal is not handled when using
 `functools.partails` to connect to a function when `DEBUG=False`.

 We have the following code:
 {{{#!python
 from functools import partial
 from django import dispatch


 signal_name = django_dispatch.Signal()
 signal_name.connect(
 partial(signal_handler, some_attr=False),
 sender=model
 )
 }}}

 When debug is `True` and the signal is fired, then the function
 `signal_handler` is executed.
 However, when debug is `False`, the code is not executed.

 I added a print statement at the start of the function, and the function
 does not read `settings.DEBUG`.

-- 
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/0107017f59d0cfc7-6f2f4fad-5ab5-4aa3-a7de-d9105b298bd7-00%40eu-central-1.amazonses.com.


Re: [Django] #31169: Allow parallel test runner to work with Windows/macOS `spawn` process start method.

2022-03-05 Thread Django
#31169: Allow parallel test runner to work with Windows/macOS `spawn` process 
start
method.
-+-
 Reporter:  Brandon Navra|Owner:  David
 |  Smith
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by GitHub ):

 In [changeset:"795da6306a048b18c0158496b0d49e8e4f197a32" 795da630]:
 {{{
 #!CommitTicketReference repository=""
 revision="795da6306a048b18c0158496b0d49e8e4f197a32"
 Refs #31169 -- Prevented infinite loop in tests on failures.

 Regression in ae91ecf6a1037fb67d14841b66ac19d4c2ccc4ac.
 }}}

-- 
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/0107017f59d0d408-51f4ad45-d754-417b-83b0-c3224afe3bc2-00%40eu-central-1.amazonses.com.


Re: [Django] #27624: Optimize ORM by using more immutable data structures

2022-03-05 Thread Django
#27624: Optimize ORM by using more immutable data structures
-+-
 Reporter:  Adam Johnson |Owner:  Adam
 Type:   |  Johnson
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  1.10
  (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 Mariusz Felisiak ):

 In [changeset:"24cc51f8fb62102a67d16cef1e0748d45afe25f4" 24cc51f8]:
 {{{
 #!CommitTicketReference repository=""
 revision="24cc51f8fb62102a67d16cef1e0748d45afe25f4"
 Refs #27624 -- Optimized Query.clone() a bit.
 }}}

-- 
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/0107017f59d0d303-9f6476b2-11c1-44d6-ab70-b533b7d6740d-00%40eu-central-1.amazonses.com.


[Django] #33550: Unexpected on_delete behavior in apps that have been removed from INSTALLED_APPS

2022-03-05 Thread Django
#33550: Unexpected on_delete behavior in apps that have been removed from
INSTALLED_APPS
-+-
   Reporter:  Tobias |  Owner:  nobody
  Bengfort   |
   Type: | Status:  new
  Uncategorized  |
  Component: |Version:  4.0
  Documentation  |   Keywords:  INSTALLED_APPS
   Severity:  Normal |  ForeignKey on_delete
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 If I remove an app from ''INSTALLED_APPS'' that contains models with
 ForeignKeys to other apps, the python-level ''on_delete'' is removed but
 the database level foreign key constraint still exists. The residual
 ForeignKeys can then block the deletion of other content.

 I guess the proper way to deal with this is to drop all tables belonging
 to the removed app. There should be a warning about this in the
 documentation.

 An alternative approach could be to allow database-level ''on_delete''
 (see [[ticket:21961]])

-- 
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/0107017f59d0d22c-5d31f8f8-61ab-42d6-9f7e-36f79255b3a9-00%40eu-central-1.amazonses.com.


Re: [Django] #33562: set_cookie and set_signed_cookie should accept timedelta object for max_age argument

2022-03-05 Thread Django
#33562: set_cookie and set_signed_cookie should accept timedelta object for 
max_age
argument
---+--
 Reporter:  Luke Plant |Owner:  Luke Plant
 Type:  New feature|   Status:  assigned
Component:  HTTP handling  |  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
---+--
Changes (by Luke Plant):

 * owner:  nobody => Luke Plant
 * status:  new => assigned


Comment:

 PR here - https://github.com/django/django/pull/15481

-- 
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/0107017f59d0d257-e73f014c-f754-422c-a3dc-6d7552e24af8-00%40eu-central-1.amazonses.com.


Re: [Django] #33547: Admin TabularInline with readonly field fail to render on validation error

2022-03-05 Thread Django
#33547: Admin TabularInline with readonly field fail to render on validation 
error
-+-
 Reporter:  David Glenck |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  4.0
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  tabularinline| Triage Stage:  Ready for
  readonly   |  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:"82f25266bfd367d5acd43f7cb502850146e9a53e" 82f25266]:
 {{{
 #!CommitTicketReference repository=""
 revision="82f25266bfd367d5acd43f7cb502850146e9a53e"
 [4.0.x] Fixed #33547 -- Fixed error when rendering invalid inlines with
 readonly fields in admin.

 Regression in de95c826673be9ea519acc86fd898631d1a11356.

 Thanks David Glenck for the report.
 Backport of 445b075def2c037b971518963b70ce13df5e88a2 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/0107017f59d0d210-f4150853-29b2-4517-9865-a97e09ad18d6-00%40eu-central-1.amazonses.com.


Re: [Django] #33552: SQLite JSONField() doesn't handle numerical has_key lookups

2022-03-05 Thread Django
#33552: SQLite JSONField() doesn't handle numerical has_key lookups
-+-
 Reporter:  TheTerrasque |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.0
  (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 TheTerrasque:

Old description:

> == Problem
> When using
> models.[https://docs.djangoproject.com/en/4.0/ref/models/fields/#jsonfield
> JSONField]() [https://docs.djangoproject.com/en/4.0/topics/db/queries
> /#has-key has_key] lookup with numerical keys on SQLite database it fails
> to find the keys.
>
> == Versions:
>   Django: 4.0.3
>   Python: 3.9.6 (tags/v3.9.6:db3ff76, Jun 28 2021, 15:26:21) [MSC v.1929
> 64 bit (AMD64)] on win32
>
> == Example:
>
> === Database
>

> {{{
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.db.backends.sqlite3',
> 'NAME': 'db.sqlite3',
> }
> }
> }}}
>

> === Model
>

> {{{
> class JsonFieldHasKeyTest(models.Model):
> data = models.JSONField()
> }}}
>
> === Test
>
> {{{
> from django.test import TestCase
> from .models import JsonFieldHasKeyTest
>
> class JsonFieldHasKeyTestCase(TestCase):
> def setUp(self) -> None:
> test = JsonFieldHasKeyTest(data={'foo': 'bar'})
> test2 = JsonFieldHasKeyTest(data={'': 'bar'})
> test.save()
> test2.save()
>
> def test_json_field_has_key(self):
> c1 =
> JsonFieldHasKeyTest.objects.filter(data__has_key='foo').count()
> c2 =
> JsonFieldHasKeyTest.objects.filter(data__has_key='').count()
> self.assertEqual(c1, 1, "Should have found 1 entry with key
> 'foo'")
> self.assertEqual(c2, 1, "Should have found 1 entry with key
> ''")
> }}}
>
> === Result
>
> {{{
> FAIL: test_json_field_has_key (markers.tests.JsonFieldHasKeyTestCase)
> --
> Traceback (most recent call last):
>   File
> "H:\Files\Projects\Electaco\Webservice\elecserve\markers\tests.py", line
> 16, in test_json_field_has_key
> self.assertEqual(c2, 1, "Should have found 1 entry with key ''")
> AssertionError: 0 != 1 : Should have found 1 entry with key ''
> }}}
>
> == Additional info
> This has been tested on SQLite and Postgresql backend, it works on
> postgresql but fails on sqlite.

New description:

 == Problem
 When using
 models.[https://docs.djangoproject.com/en/4.0/ref/models/fields/#jsonfield
 JSONField]() [https://docs.djangoproject.com/en/4.0/topics/db/queries
 /#has-key has_key] lookup with numerical keys on SQLite database it fails
 to find the keys.

 == Versions:
   Django: 4.0.3
   Python: 3.9.6 (tags/v3.9.6:db3ff76, Jun 28 2021, 15:26:21) [MSC v.1929
 64 bit (AMD64)] on win32
   sqlite3.version: '2.6.0'
   sqlite3.sqlite_version: '3.35.5'

 == Example:

 === Database


 {{{
 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.sqlite3',
 'NAME': 'db.sqlite3',
 }
 }
 }}}


 === Model


 {{{
 class JsonFieldHasKeyTest(models.Model):
 data = models.JSONField()
 }}}

 === Test

 {{{
 from django.test import TestCase
 from .models import JsonFieldHasKeyTest

 class JsonFieldHasKeyTestCase(TestCase):
 def setUp(self) -> None:
 test = JsonFieldHasKeyTest(data={'foo': 'bar'})
 test2 = JsonFieldHasKeyTest(data={'': 'bar'})
 test.save()
 test2.save()

 def test_json_field_has_key(self):
 c1 =
 JsonFieldHasKeyTest.objects.filter(data__has_key='foo').count()
 c2 =
 JsonFieldHasKeyTest.objects.filter(data__has_key='').count()
 self.assertEqual(c1, 1, "Should have found 1 entry with key
 'foo'")
 self.assertEqual(c2, 1, "Should have found 1 entry with key
 ''")
 }}}

 === Result

 {{{
 FAIL: test_json_field_has_key (markers.tests.JsonFieldHasKeyTestCase)
 --
 Traceback (most recent call last):
   File "H:\Files\Projects\Electaco\Webservice\elecserve\markers\tests.py",
 line 16, in test_json_field_has_key
 self.assertEqual(c2, 1, "Should have found 1 entry with key ''")
 AssertionError: 0 != 1 : Should have found 1 entry with key ''
 }}}

 == Additional info
 This has been tested on SQLite and Postgresql backend, it works on
 postgresql but fails on sqlite.

--

-- 
Ticket URL: