Re: [Django] #33930: Add id="deleted-objects" to template admin/delete_confirmation.html

[Django]

#33930: Add id="deleted-objects" to template admin/delete_confirmation.html
-+-
 Reporter:  Jacob Rief   |Owner:  Jacob
 Type:   |  Rief
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  admin/delete_confirmation.html |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Changes (by Mariusz Felisiak):

 * type:  New feature => Cleanup/optimization
 * 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/01070182aa7db7a8-e15c1d82-9403-43d5-ac2a-04fcd7e72b47-00%40eu-central-1.amazonses.com.

[Django] #33930: Add id="deleted-objects" to template admin/delete_confirmation.html

[Django]

#33930: Add id="deleted-objects" to template admin/delete_confirmation.html
-+-
   Reporter:  Jacob  |  Owner:  Jacob Rief
  Rief   |
   Type:  New| Status:  assigned
  feature|
  Component: |Version:  dev
  contrib.admin  |   Keywords:
   Severity:  Normal |  admin/delete_confirmation.html
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  1  |
-+-
 As discussed on the developers mailing list, see
 https://groups.google.com/g/django-developers/c/VTRqW7ZmB6A ,
 is would make sense to add id="deleted-objects" to the  element
 showing the objects to be deleted.

 Reason:
 Whenever a user attempts to delete an object inside the Django admin,
 a delete confirmation page is shown. If the object to be deleted contains
 many relations, the user is overwhelmed with a list of other objects to be
 deleted together with the current object. Often those objects are just
 internal relations the user never heard of, and this may be unsettling.

 By overriding that template one can use CSS to hide this list and add a
 short
 JavaScript snippet to unhide if 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/01070182aa798bae-86366f06-faad--bc14-0c7897dd90fb-00%40eu-central-1.amazonses.com.

Re: [Django] #33929: Field Reference in FilteredRelation Does Not Recognize Previously Defined FilteredRelation

[Django]

#33929: Field Reference in FilteredRelation Does Not Recognize Previously 
Defined
FilteredRelation
-+-
 Reporter:  Matt |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.1
  (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
-+-

Comment (by Simon Charette):

 I agree with Mariusz and I think this has the exact same root cause as
 #33766 and detailed in
 [https://code.djangoproject.com/ticket/33766#comment:5 this comment].

 The gist of it is that filter relations
 
[https://github.com/django/django/blob/9dff316be41847c505ebf397e4a52a0a71e0acc4/django/db/models/query_utils.py#L376-L380
 conditions are resolved very late in the process of SQL compilation]
 (basically when the `FROM` clause is generated) and thus the resolving of
 references to filtered relation induced joins alias can be  off.

-- 
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/01070182aa42f5f6-23e8741f-2333-4866-a2be-ccf8a6ce26bc-00%40eu-central-1.amazonses.com.

Re: [Django] #33766: FilteredRelation resolves its conditions too late which can result in unknown alias references at SQL compilation time

[Django]

#33766: FilteredRelation resolves its conditions too late which can result in
unknown alias references at SQL compilation time
-+-
 Reporter:  Daniel Schaffer  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  filteredrelation | Triage Stage:  Accepted
  coalesce   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 #33929 was closed as a duplicate. We should add tests for #33929 when
 resolving this issue.

-- 
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/01070182aa41aa88-c5d6ebca-83fe-4958-80aa-a6e59d025dd4-00%40eu-central-1.amazonses.com.

Re: [Django] #33929: Field Reference in FilteredRelation Does Not Recognize Previously Defined FilteredRelation

[Django]

#33929: Field Reference in FilteredRelation Does Not Recognize Previously 
Defined
FilteredRelation
-+-
 Reporter:  Matt |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.1
  (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:

 Thanks for the report! Agree, this is a duplicate of #33929.

-- 
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/01070182aa406da1-56e15316-62a8-48a2-b8da-15f97dac6473-00%40eu-central-1.amazonses.com.

Re: [Django] #33928: Performance issues with `on_delete=models.SET_NULL` on large tables

[Django]

#33928: Performance issues with `on_delete=models.SET_NULL` on large tables
-+-
 Reporter:  Renan GEHAN  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  3.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 Simon Charette):

 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 You are right that is an opportunity for an optimization when `SET`,
 `SET_DEFAULT`, or `SET_NULL` is used  but I wonder if it's worth doing
 given `db_on_delete` support (see #21961) make things even better for this
 use case.

 > In the meantime, I'll switch to on_delete=models.CASCADE, which in my
 case does the trick, but I was curious about the reason why this happens
 in the first place.

 This is likely the case because the collector is able to take
 
[https://github.com/django/django/blob/08688bd7dd8dfa218ecff03d6c94a753b1be8e59/django/db/models/deletion.py#L318-L320
 the fast delete route] and avoid object fetching entirely.

 If you want to give a shot at a patch you'll want to have a look at
 `Collector.collect` and have it skip collection entirely when dealing with
 `SET` and friends likely by adding a branch that turns them into ''fast''
 updates.
 
[https://github.com/django/django/blob/08688bd7dd8dfa218ecff03d6c94a753b1be8e59/django/db/models/deletion.py#L500-L504
 One branch that worries me is the post-deletion assignment of values to
 in-memory instances] but I can't understand why this is even necessary
 given all the instances that are collected for field updates are never
 make their way out of the collector so I would expect it to be entirely
 unnecessary.

 You'll want to make sure to avoid breaking the
 
[https://github.com/django/django/blob/0dd29209091280ccf34e07c9468746c396b7778e/django/contrib/admin/utils.py#L164-L228
 admin's collector subclass used to display deletion confirmation pages]
 but from a quick look it doesn't seem to care about field updates.

 Tentatively accepting but I think we should revisit when #21961 lands. In
 the mean time if you want to give a shot at implementing this optimization

-- 
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/01070182aa3038ac-53e176d9-a3da-4a04-851c-5236e720fd17-00%40eu-central-1.amazonses.com.

Re: [Django] #28806: Mechanism of fetching related objects violates READ COMMITTED assumption of Django ORM

[Django]

#28806: Mechanism of fetching related objects violates READ COMMITTED 
assumption of
Django ORM
-+-
 Reporter:  Aaron Tan|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  database, read-  | Triage Stage:  Accepted
  committed, concurrency control |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 I would agree that there is little Django can do here and that we should
 likely close this issue as ''wontfix'' and move on. Silencing errors would
 do more harm than good as previous at accessing `fk_id` could have
 returned a value but then `fk` would be `None`?

 We could adjust the comment but ultimately the only way to ensure the
 retrieval of a graph of object that is coherent at query time is to use
 `select_related` to ensure all the data is retrieved a single query. From
 that time objects are not locked anyhow and the only way to ensure they
 are not altered is to use `select_for_update` and friends.

 I would argue that lazy fetching of related objects honours `READ
 COMMITED` assumption of the ORM; if you defer relationship then fetching
 at a later point in time will attempt to reconciliate your in-memory
 representation of model instances with the latest committed database state
 possibly resulting in exceptions.

-- 
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/01070182aa10868d-7827f0ad-0595-4b3a-a514-44ccab4499ab-00%40eu-central-1.amazonses.com.

Re: [Django] #33929: Field Reference in FilteredRelation Does Not Recognize Previously Defined FilteredRelation

[Django]

#33929: Field Reference in FilteredRelation Does Not Recognize Previously 
Defined
FilteredRelation
-+-
 Reporter:  Matt |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Nick Vellios):

 I hope to add some more context after looking this over.  It appears as
 though Matt is correct regarding being related to
 https://code.djangoproject.com/ticket/33766.  The fields are not being
 properly aliased.

 App name in my tests is `interface` which I left references of in the
 console output, but I removed the `interface_` prefix from the formatted
 SQL queries for readability.

 {{{
 >>> qs = A.objects.annotate(
 ... binc=FilteredRelation("b", condition=Q(b__complete=False)),
 ... cinc=FilteredRelation("c", condition=Q(c__b=F("binc__pk"),
 c__complete=False)),
 ... b_count=Count("binc"),
 ... c_count=Count("cinc"),
 ... )
 >>> qs.query.alias_map
 {'interface_a': , 'binc': , 'cinc': }
 }}}

 Invoking the query compiler adds the naive alias `T4` to the query which
 also later shows up in the `Query.alias_map`.
 {{{
 >>> str(qs.query)

 SELECT
   "a"."id",
   COUNT(binc."id") AS "b_count",
   COUNT(cinc."id") AS "c_count"
 FROM "a"
 LEFT OUTER JOIN "b" binc
   ON ("a"."id" = binc."a_id"
   AND (NOT binc."complete"))
 LEFT OUTER JOIN "c" cinc
   ON ("a"."id" = cinc."a_id"
   AND ((cinc."b_id" = (T4."id")
   AND NOT cinc."complete")))
 GROUP BY "a"."id"
 }}}

 Notice the incrementing `Tn` on the `Query.alias_map` but only the last
 one is referenced in the resulting query:

 {{{
 >>> qs.query.alias_map
 {'interface_a': , 'binc': , 'cinc': , 'T4': , 'T5':
 }

 >>> str(qs.query)
 'SELECT "interface_a"."id", COUNT(binc."id") AS "b_count",
 COUNT(cinc."id") AS "c_count" FROM "interface_a" LEFT OUTER JOIN
 "interface_b" binc ON ("interface_a"."id" = binc."a_id" AND (NOT
 binc."complete")) LEFT OUTER JOIN "interface_c" cinc ON
 ("interface_a"."id" =
  cinc."a_id" AND ((cinc."b_id" = (T6."id") AND NOT cinc."complete")))
 GROUP BY "interface_a"."id"'

 >>> str(qs.query)
 'SELECT "interface_a"."id", COUNT(binc."id") AS "b_count",
 COUNT(cinc."id") AS "c_count" FROM "interface_a" LEFT OUTER JOIN
 "interface_b" binc ON ("interface_a"."id" = binc."a_id" AND (NOT
 binc."complete")) LEFT OUTER JOIN "interface_c" cinc ON
 ("interface_a"."id" =
  cinc."a_id" AND ((cinc."b_id" = (T8."id") AND NOT cinc."complete")))
 GROUP BY "interface_a"."id"'

 >>> qs.query.alias_map
 {'interface_a': , 'binc': , 'cinc': , 'T4': , 'T5':
 , 'T6':
 , 'T7':
 , 'T8':
 , 'T9':
 }


 >>> str(qs.query)

 SELECT
   "a"."id",
   COUNT(binc."id") AS "b_count",
   COUNT(cinc."id") AS "c_count"
 FROM "a"
 LEFT OUTER JOIN "b" binc
   ON ("a"."id" = binc."a_id"
   AND (NOT binc."complete"))
 LEFT OUTER JOIN "c" cinc
   ON ("a"."id" = cinc."a_id"
   AND ((cinc."b_id" = (T9"id")
   AND NOT cinc."complete")))
 GROUP BY "a"."id"

 }}}

 The following works but selects and groups by one additional field
 `binc_pk`.  Postgres Query Planner output included.  On a larger queryset
 this could get expensive.

 {{{
 A.objects.annotate(
 binc=FilteredRelation("b", condition=Q(b__complete=False)),
 binc_pk=F('binc__pk'),  # <-- Allows elimination of relying on raw
 SQL, however...
 cinc=FilteredRelation("c", condition=Q(c__b=F('binc_pk'),
 c__complete=False)),
 b_count=Count("binc"),
 c_count=Count("cinc"),
 )
 }}}

 {{{
 SELECT
   "a"."id",
   binc."id" AS "binc_pk",  /* <-- Ugly */
   COUNT(binc."id") AS "b_count",
   COUNT(cinc."id") AS "c_count"
 FROM "a"
 LEFT OUTER JOIN "b" binc
   ON ("a"."id" = binc."a_id"
   AND (NOT binc."complete"))
 LEFT OUTER JOIN "c" cinc
   ON ("a"."id" = cinc."a_id"
   AND ((cinc."b_id" = (binc."id")
   AND NOT cinc."complete")))
 GROUP BY "a"."id",
   binc."id"  /* <-- Ugly */
 }}}

 Not ideal.

 {{{
 ➜  ~ psql -d dj_issue_33929
 psql (14.4)
 Type "help" for help.

 dj_issue_33929=# EXPLAIN SELECT
 dj_issue_33929-#   "interface_a"."id",
 dj_issue_33929-#   binc."id" AS "binc_pk",
 dj_issue_33929-#   COUNT(binc."id") AS "b_count",
 dj_issue_33929-#   COUNT(cinc."id") AS "c_count"
 dj_issue_33929-# FROM "interface_a"
 dj_issue_33929-# LEFT OUTER JOIN "interface_b" binc
 dj_issue_33929-#   ON ("interface_a"."id" = binc."a_id"
 dj_issue_33929(#   AND (NOT binc."complete"))
 dj_issue_33929-# LEF

[Django] #33929: Field Reference in FilteredRelation Does Not Recognize Previously Defined FilteredRelation

[Django]

#33929: Field Reference in FilteredRelation Does Not Recognize Previously 
Defined
FilteredRelation
-+-
   Reporter:  Matt   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  4.1
  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 suspect this may be the same root cause as
 https://code.djangoproject.com/ticket/33766, but the use-case here is
 different enough I thought I'd log a new ticket.

 All this is using Django 4.0 or 4.1, on PostgreSQL.  I confess that I have
 not checked if other DB layers might generate correct SQL.

 It appears that I cannot reference one FilteredRelation from another's
 condition without jumping through some hoops.  Starting with the following
 example models:
 {{{
 from django.db import models

 class A(models.Model):
 ...

 class B(models.Model):
 a = models.ForeignKey("A", on_delete=models.CASCADE)
 complete = models.BooleanField(default=False)

 class C(models.Model):
 a = models.ForeignKey("A", on_delete=models.CASCADE)
 b = models.OneToOneField("B", blank=True, null=True,
 on_delete=models.CASCADE)
 complete = models.BooleanField(default=False)
 }}}

 Now suppose that I want a count of incomplete B, and also incomplete C,
 but only when related to an incomplete B.
 If I were writing SQL myself, I’d write this as:
 {{{
 SELECT COUNT(b.id) as b_count, COUNT(c.id) as c_count
 FROM a
 LEFT JOIN b ON b.a_id = a.id AND NOT b.complete
 LEFT JOIN c ON c.a_id = a.id AND c.b_id = b.id AND NOT c.complete
 }}}

 Now, the below queryset very nearly works:
 {{{
 A.objects.annotate(
 binc=FilteredRelation("b", condition=Q(b__complete=False)),
 cinc=FilteredRelation("c", condition=Q(c__b=F("binc__pk"),
 c__complete=False)),
 b_count=Count("binc"),
 c_count=Count("cinc"),
 )
 }}}

 Unfortunately this uses an incorrect table alias into the `cinc`
 FilteredRelation, where I tried to reference `F("binc__pk")`.  If I try to
 execute it, I get
 {{{
 django.db.utils.ProgrammingError: missing FROM-clause entry for table "t4"
 LINE 1: ...("a"."id" = cinc."a_id" AND ((cinc."b_id" = (T4."id") A…
 }}}

 There is a workaround: I can force the correct identifier using RawSQL,
 and use this, which provides correct results:

 {{{
 A.objects.annotate(
 binc=FilteredRelation("b", condition=Q(b__complete=False)),
 cinc=FilteredRelation("c", condition=Q(c__b=RawSQL("binc.id", ()),
 c__complete=False)),
 b_count=Count("binc"),
 c_count=Count("cinc"),
 )
 }}}

-- 
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/01070182a91335db-7b51b27c-9705-47b7-aa12-0f00dab94898-00%40eu-central-1.amazonses.com.

[Django] #33928: Performance issues with `on_delete=models.SET_NULL` on large tables

[Django]

#33928: Performance issues with `on_delete=models.SET_NULL` on large tables
-+-
   Reporter:  Renan  |  Owner:  nobody
  GEHAN  |
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  3.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  |
-+-
 Hello,

 I have the following models configuration:
 - `Parent` model
 - `Child` model, with a `parent_id` foreign key to a `Parent` model, set
 with `on_delete=models.SET_NULL`

 Each `Parent` can have a lot of children, in my case roughly 30k.

 I'm starting to encounter performance issues that make my jobs timeout,
 because the SQL queries simply timeout.

 I've enabled query logging, and noticed something weird (that is certainly
 that way on purpose, but I don't understand why).

 {{{
 # Select the parent
 SELECT * FROM "parent" WHERE "parent"."id" = 'parent123';

 # Select all children
 SELECT * FROM "children" WHERE "children"."parent_id" IN ('parent123');

 # Update all children `parent_id` column to `NULL`
 UPDATE "children" SET "parent_id" = NULL WHERE "children"."id" IN
 ('child1', 'child2', 'child3', ..., 'child3');

 # Finally delete the parent
 DELETE FROM "parent" WHERE "parent"."id" IN ('parent123');
 }}}

 I would have expected the update condition to simply be `WHERE
 "children"."parent_id" = 'parent123'`, but for some reason it isn't.

 In the meantime, I'll switch to `on_delete=models.CASCADE`, which in my
 case does the trick, but I was curious about the reason why this happens
 in the first place.

 Thanks in advance

-- 
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/01070182a82044c5-41d2d108-52da-49f1-b1ab-122329c5c3ee-00%40eu-central-1.amazonses.com.

Re: [Django] #26355: Add support for PostgreSQL's array_append to ArrayField

[Django]

#26355: Add support for PostgreSQL's array_append to ArrayField
--+
 Reporter:  Paul Grau |Owner:  (none)
 Type:  New feature   |   Status:  new
Component:  contrib.postgres  |  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):

 * owner:  Asif Saifuddin Auvi => (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/01070182a7eec7e1-2bc5a1e7-df6c-4fa0-9744-1552c989b7af-00%40eu-central-1.amazonses.com.

Re: [Django] #28861: Add schema tests for CIText fields

[Django]

#28861: Add schema tests for CIText fields
-+-
 Reporter:  Tim Graham   |Owner:  (none)
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.postgres |  Version:  dev
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * status:  new => closed
 * resolution:   => invalid
 * stage:  Accepted => Unreviewed


Comment:

 `CIText` is deprecated and will be removed in Django 5.1, see
 cb791a2540c289390b68a3ea9c6a79476890bab2.

-- 
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/01070182a7eda67e-5be93506-7102-4b53-a303-209a1b09b1ee-00%40eu-central-1.amazonses.com.

Re: [Django] #33491: Rows are selected only on Chrome when going back from the confirmation page.

[Django]

#33491: Rows are selected only on Chrome when going back from the confirmation
page.
-+-
 Reporter:  Akihito Yokose   |Owner:  Marcelo
 Type:   |  Galigniana
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  3.2
 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 Marcelo Galigniana):

 * needs_better_patch:  1 => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070182a7e3dc1b-84624117-7c8c-4ce6-b0fd-d6515ad8ee97-00%40eu-central-1.amazonses.com.

Re: [Django] #33927: Rendering a read-only ArrayField with choices crashes. (was: Rendering an ArrayField as read-only in admin raises TypeError)

[Django]

#33927: Rendering a read-only ArrayField with choices crashes.
---+
 Reporter:  David Svenson  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  3.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Mariusz Felisiak):

 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the report. `ArrayField` must have `choices` to reproduce this
 issue, e.g.
 {{{#!python
 field_2 = ArrayField(models.IntegerField(), choices=[
 ([1, 2, 3], "base choice"),
 ([1, 2], "1st choice"),
 ([2, 3], "2nd choice"),
 ])
 }}}
 We could try to call `make_hashable()` on the `flatchoices` and `value`:
 {{{#!diff
 diff --git a/django/contrib/admin/utils.py b/django/contrib/admin/utils.py
 index 6cb549fb10..3e09153138 100644
 --- a/django/contrib/admin/utils.py
 +++ b/django/contrib/admin/utils.py
 @@ -10,6 +10,7 @@ from django.db.models.deletion import Collector
  from django.forms.utils import pretty_name
  from django.urls import NoReverseMatch, reverse
  from django.utils import formats, timezone
 +from django.utils.hashable import make_hashable
  from django.utils.html import format_html
  from django.utils.regex_helper import _lazy_re_compile
  from django.utils.text import capfirst
 @@ -401,7 +402,7 @@ def display_for_field(value, field,
 empty_value_display):
  from django.contrib.admin.templatetags.admin_list import
 _boolean_icon

  if getattr(field, "flatchoices", None):
 -return dict(field.flatchoices).get(value, empty_value_display)
 +return
 dict(make_hashable(field.flatchoices)).get(make_hashable(value),
 empty_value_display)
  # BooleanField needs special-case null-handling, so it comes before
 the
  # general null test.
  elif isinstance(field, models.BooleanField):
 }}}
 but this can cause a performance regression.

-- 
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/01070182a7da7ea1-bd6eef31-271a-4384-a557-9de160fdd178-00%40eu-central-1.amazonses.com.

Re: [Django] #29850: Add window support for RowRange frames

[Django]

#29850: Add window support for RowRange frames
-+-
 Reporter:  Daniel Fuchs |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  GSoC | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by John Speno):

 * cc: John Speno (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/01070182a7b7ed63-5081522d-06f3-434d-9e50-9011cc5284cd-00%40eu-central-1.amazonses.com.

Re: [Django] #33871: JSONField with default is not detected as changed when invalidated in inlines.

[Django]

#33871: JSONField with default is not detected as changed when invalidated in
inlines.
-+-
 Reporter:  Raphael  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  JSONField| Triage Stage:  Accepted
  TabularInline  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 Replying to [comment:6 JunKi Yoon]:
 > Is this still a bug that needs to be fixed?

 Yes, it's waiting for a patch.

-- 
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/01070182a743c992-a8599c5b-2f08-46ca-9f7c-d2ddc80a546e-00%40eu-central-1.amazonses.com.

Re: [Django] #17688: No m2m_changed signal sent to when referenced object is deleted

[Django]

#17688: No m2m_changed signal sent to when referenced object is deleted
-+-
 Reporter:  jblaine@…|Owner:
 |  jorgecarleitao
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.3
  (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
-+-

Comment (by Stephen Wolff):

 I can see `pre_remove` and `post_remove` now in the `m2m_changed`
 documentation:

  - https://docs.djangoproject.com/en/4.1/ref/signals/#m2m-changed

 Does that mean this might have been fixed as part of a feature addition or
 something?

-- 
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/01070182a7408dd8-c5539ab7-2535-4757-83af-e891c16ee9d0-00%40eu-central-1.amazonses.com.

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

[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 Taylor H):

 Hey everyone, just wanted to mention that I created the following library
 for very fast model updates and inserts in Postgres. We have been using it
 in production for over 2 years.

 https://github.com/cedar-team/django-bulk-load

 More details about the library:
 https://decode.cedar.com/fast-django-model-inserts-with-postgres/

-- 
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/01070182a73a3ca2-e7e3e050-b103-4b23-b7a6-75e93ec61714-00%40eu-central-1.amazonses.com.

Re: [Django] #33878: Use system font stack in the admin

[Django]

#33878: Use system font stack in the admin
-+-
 Reporter:  Tom Carrick  |Owner:  Tom
 Type:   |  Carrick
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  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:  1
-+-
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/01070182a6f5a6a3-e2a32019-73d3-4fb7-8579-89be42a6ae51-00%40eu-central-1.amazonses.com.

[Django] #33927: Rendering an ArrayField as read-only in admin raises TypeError

[Django]

#33927: Rendering an ArrayField as read-only in admin raises TypeError
-+
   Reporter:  David Svenson  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  contrib.admin  |Version:  3.2
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 If an ''ArrayField'' is included in an ''admin.ModelAdmin'' and
 ''has_change_permission'' returns ''False'' (making the field read-only),
 an exception is thrown when the field is supposed to be rendered.

 This is the stacktrace after Django tries to render the field in
 ''django/contrib/admin/templates/admin/includes/fieldset.html''

 {{{
 Traceback (most recent call last):
   File ".venv/lib/python3.10/site-
 packages/django/core/handlers/exception.py", line 47, in inner
 response = get_response(request)
   File ".venv/lib/python3.10/site-packages/django/core/handlers/base.py",
 line 204, in _get_response
 response = response.render()
   File ".venv/lib/python3.10/site-packages/django/template/response.py",
 line 105, in render
 self.content = self.rendered_content
   File ".venv/lib/python3.10/site-packages/django/template/response.py",
 line 83, in rendered_content
 return template.render(context, self._request)
   File ".venv/lib/python3.10/site-
 packages/django/template/backends/django.py", line 61, in render
 return self.template.render(context)
   File ".venv/lib/python3.10/site-packages/django/template/base.py", line
 170, in render
 return self._render(context)
   File ".venv/lib/python3.10/site-packages/django/template/base.py", line
 162, in _render
 return self.nodelist.render(context)
   File ".venv/lib/python3.10/site-packages/django/template/base.py", line
 938, in render
 bit = node.render_annotated(context)
   File ".venv/lib/python3.10/site-packages/django/template/base.py", line
 905, in render_annotated
 return self.render(context)
   File ".venv/lib/python3.10/site-
 packages/django/template/loader_tags.py", line 150, in render
 return compiled_parent._render(context)
   File ".venv/lib/python3.10/site-packages/django/template/base.py", line
 162, in _render
 return self.nodelist.render(context)
   File ".venv/lib/python3.10/site-packages/django/template/base.py", line
 938, in render
 bit = node.render_annotated(context)
   File ".venv/lib/python3.10/site-packages/django/template/base.py", line
 905, in render_annotated
 return self.render(context)
   File ".venv/lib/python3.10/site-
 packages/django/template/loader_tags.py", line 150, in render
 return compiled_parent._render(context)
   File ".venv/lib/python3.10/site-packages/django/template/base.py", line
 162, in _render
 return self.nodelist.render(context)
   File ".venv/lib/python3.10/site-packages/django/template/base.py", line
 938, in render
 bit = node.render_annotated(context)
   File ".venv/lib/python3.10/site-packages/django/template/base.py", line
 905, in render_annotated
 return self.render(context)
   File ".venv/lib/python3.10/site-
 packages/django/template/loader_tags.py", line 62, in render
 result = block.nodelist.render(context)
   File ".venv/lib/python3.10/site-packages/django/template/base.py", line
 938, in render
 bit = node.render_annotated(context)
   File ".venv/lib/python3.10/site-packages/django/template/base.py", line
 905, in render_annotated
 return self.render(context)
   File ".venv/lib/python3.10/site-
 packages/django/template/loader_tags.py", line 62, in render
 result = block.nodelist.render(context)
   File ".venv/lib/python3.10/site-packages/django/template/base.py", line
 938, in render
 bit = node.render_annotated(context)
   File ".venv/lib/python3.10/site-packages/django/template/base.py", line
 905, in render_annotated
 return self.render(context)
   File ".venv/lib/python3.10/site-
 packages/django/template/defaulttags.py", line 214, in render
 nodelist.append(node.render_annotated(context))
   File ".venv/lib/python3.10/site-packages/django/template/base.py", line
 905, in render_annotated
 return self.render(context)
   File ".venv/lib/python3.10/site-
 packages/django/template/loader_tags.py", line 195, in render
 return template.render(context)
   File ".venv/lib/python3.10/site-packages/django/template/base.py", line
 172, in render
 return self._render(context)
   File ".venv/lib/python3.10/site-packages/django/template/base.py", line
 162, in _render
 return self.nodelist.render(context)
   File ".venv/lib/python3.10/site-packages/django/template/base.py", line
 938, in render
 bit =

Re: [Django] #33878: Use system font stack in the admin

[Django]

#33878: Use system font stack in the admin
-+-
 Reporter:  Tom Carrick  |Owner:  Tom
 Type:   |  Carrick
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  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:  1
-+-
Changes (by Tom Carrick):

 * needs_docs:  1 => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070182a6b02263-4b5694f6-aa37-4f89-b270-b5b1aec6677d-00%40eu-central-1.amazonses.com.

Re: [Django] #33871: JSONField with default is not detected as changed when invalidated in inlines.

[Django]

#33871: JSONField with default is not detected as changed when invalidated in
inlines.
-+-
 Reporter:  Raphael  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  JSONField| Triage Stage:  Accepted
  TabularInline  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by JunKi Yoon):

 Replying to [comment:5 Mariusz Felisiak]:

 Is this still a bug that needs to be 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/01070182a6866ecf-9c41e95a-8ac9-4790-9bd5-31881d02d39d-00%40eu-central-1.amazonses.com.

Re: [Django] #33926: Django freezes when reading data from request.body

[Django]

#33926: Django freezes when reading data from request.body
---+--
 Reporter:  sfcl   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:  3.2
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Claude Paroz):

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


Comment:

 Duplicate of #29800

-- 
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/01070182a6704fdc-f99a0b68-21b8-4b05-9cd8-9c03c66e2db3-00%40eu-central-1.amazonses.com.

[Django] #33926: Django freezes when reading data from request.body

[Django]

#33926: Django freezes when reading data from request.body
-+
   Reporter:  sfcl   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  HTTP handling  |Version:  3.2
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 Let's say we have a simple Django view:

 {{{
 def my_view(request):
 content = request.body
 # some actions with content varible
 response = HttpResponse('It work!')
 }}}

 And a simple api client, let's say based on the requests library, sending
 malformed Django view data:


 {{{
 headers = dict()
 headers['Accept'] = '*/*'
 headers['Content-Length'] = '13409'
 headers['Content-Type'] = 'application/x-compressed'
 headers['Expect'] = '100-continue'
 headers['Host'] = '127.0.0.1:8000'
 headers['User-Agent'] = 'Api client'
 headers['content-encoding'] = 'gzip'

 url = 'http://127.0.0.1:8000/api'

 request_body = ''
 r = requests.post(
 url,
 data=request_body,
 headers=headers
 )
 }}}

 As you can see, request_body contains an empty string, but the Content-
 Length header stores the value 13409. When such a request arrives, Django
 hangs on the line reading request.body. No exceptions occur. How to solve
 this problem? I cannot influence the client, so the only thing I can do is
 rewrite the Django view. Django version 3.2.15 is used.

-- 
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/01070182a667747f-4960065a-010a-426c-9ca3-489f29dfcfcf-00%40eu-central-1.amazonses.com.

Re: [Django] #28405: CICharField on a ModelFormSet doesn't catch unique constraint violations with different capitalization

[Django]

#28405: CICharField on a ModelFormSet doesn't catch unique constraint violations
with different capitalization
--+-
 Reporter:  Jon Dufresne  |Owner:  (none)
 Type:  Bug   |   Status:  closed
Component:  contrib.postgres  |  Version:  1.11
 Severity:  Normal|   Resolution:  duplicate
 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:  new => closed
 * resolution:   => duplicate


Comment:

 Marking as a duplicate of #23964 (see
 [https://code.djangoproject.com/ticket/23964#comment:9 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/01070182a5ec1e2b-96fd5c27-08a5-483a-bb49-ef612c1aab85-00%40eu-central-1.amazonses.com.

Re: [Django] #23964: Support for Meta.constraints validation in BaseModelFormSet.validate_unique(). (was: MySQL: BaseModelFormSet.validate_unique() fails for mixed case; )

[Django]

#23964: Support for Meta.constraints validation in
BaseModelFormSet.validate_unique().
--+
 Reporter:  Jon Dufresne  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Forms |  Version:  1.7
 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):

 As far as I'm aware adding support for `Meta.constraints` validation in
 `BaseModelFormSet.validate_unique()` should solve this and related issues
 (#28405). It should be feasible to pass all values from the formset via a
 constraint definition and check for duplicated rows on the database level.

-- 
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/01070182a5ebc0f7-1ba9953f-e132-417a-a980-a5f429c2c019-00%40eu-central-1.amazonses.com.

Re: [Django] #33878: Use system font stack in the admin

[Django]

#33878: Use system font stack in the admin
-+-
 Reporter:  Tom Carrick  |Owner:  Tom
 Type:   |  Carrick
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Carlton Gibson):

 * needs_docs:  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/01070182a5e05864-54f6b5d0-eab7-428d-96b8-eba6f6403ea6-00%40eu-central-1.amazonses.com.

Re: [Django] #25617: Disallow usernames that differ only in case in UserCreationForm

[Django]

#25617: Disallow usernames that differ only in case in UserCreationForm
--+
 Reporter:  Tim Graham|Owner:  (none)
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.auth  |  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):

 * owner:  Neven Munđar => (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/01070182a5d456f4-468ac9b1-539b-4b72-ba6e-eda423c1d9fe-00%40eu-central-1.amazonses.com.

Re: [Django] #33491: Rows are selected only on Chrome when going back from the confirmation page.

[Django]

#33491: Rows are selected only on Chrome when going back from the confirmation
page.
-+-
 Reporter:  Akihito Yokose   |Owner:  Marcelo
 Type:   |  Galigniana
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * 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/01070182a5a4b8e9-92657dfb-88a1-4778-8892-3159b37d23ef-00%40eu-central-1.amazonses.com.