Re: [Django] #32993: Refactor AutocompleteJsonView to support extra fields in autocomplete response

[Django]

#32993: Refactor AutocompleteJsonView to support extra fields in autocomplete
response
-+-
 Reporter:  mrts |Owner:  mrts
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  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:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"9b1158a7e0784686bbe5118a88d4804b99fa4fe1" 9b1158a7]:
 {{{
 #!CommitTicketReference repository=""
 revision="9b1158a7e0784686bbe5118a88d4804b99fa4fe1"
 Fixed #32993 -- Added AutocompleteJsonView.serialize_result() to allow
 customization.
 }}}

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

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

Re: [Django] #32999: Admin Tabular Stacked Inline widget headings are not aligned headings

[Django]

#32999: Admin Tabular Stacked Inline widget headings are not aligned headings
-+-
 Reporter:  Michael  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  contrib.admin|  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  tabularinline css| Triage Stage:
  style styling  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * Attachment "Screenshot 2021-08-10 at 08.49.16.png" added.

 Screenshot from admin showing Delete input and remove "extra" inline
 controls.

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

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

Re: [Django] #33001: ManifestStaticFilesStorage is problematic - need changes here

[Django]

#33001: ManifestStaticFilesStorage is problematic - need changes here
-+-
 Reporter:  Man Python   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  File |  Version:  3.2
  uploads/storage|
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  Static   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 Hi. This behaviour has been unchanged since
 [https://docs.djangoproject.com/en/3.2/releases/1.7/#django-contrib-
 staticfiles ManifestStaticFilesStorage was introduced in Django 1.7].
 You're welcome to make whatever adjustments you need in a subclass (or
 configure your webserver to route `styles.css?` requests to the
 right file) but it's not something we can just change.

 You say "problematic" but don't explain that at all. Likely it's your set
 up but if you can narrow down a specific issue in Django we're happy to
 have a look.
 Thanks

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

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

Re: [Django] #33007: `form_clean()` performance

[Django]

#33007: `form_clean()` performance
--+
 Reporter:  David Smith   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Forms |  Version:  3.2
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by David Smith):

 Replying to [comment:5 Carlton Gibson]:
 > But I guess details can be discussed on the django-bench repo…

 I ''finally'' got round to finishing my thoughts on benchmarking more
 generally. [https://github.com/django/djangobench/issues/38 see post].

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

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

Re: [Django] #32993: Refactor AutocompleteJsonView to support extra fields in autocomplete response

[Django]

#32993: Refactor AutocompleteJsonView to support extra fields in autocomplete
response
-+-
 Reporter:  mrts |Owner:  mrts
 Type:   |   Status:  assigned
  Cleanup/optimization   |
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:  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/062.ccdf20e83b0791e1912e85bbe2a41f22%40djangoproject.com.

Re: [Django] #33007: `form_clean()` performance

[Django]

#33007: `form_clean()` performance
--+
 Reporter:  David Smith   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Forms |  Version:  3.2
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Carlton Gibson):

 +1 to building on David's work: I believe the next stage is that we need
 to provision the benchmarks to run on small but otherwise empty instance,
 that isn't David's own machine — But I guess details can be discussed on
 the django-bench repo… — general point is it would be great to have these
 running regularly (maybe daily on main, and PRs on request?)

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

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

Re: [Django] #33009: ./manage.py test --keepdb fails when DB permissions are not sufficient

[Django]

#33009: ./manage.py test --keepdb fails when DB permissions are not sufficient
-+-
 Reporter:  Jed Laundry  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 Thanks for the report, however you using a 3rd-party database backend that
 can override `_create_test_db()`, if needed. I see you've already
 [https://github.com/microsoft/mssql-django/issues/61 reported] this on
 their issue tracker.

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

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

Re: [Django] #33004: Inconsistent / Unexpected handling of assigning unsaved model to Generic Foreign Key

[Django]

#33004: Inconsistent / Unexpected handling of assigning unsaved model to Generic
Foreign Key
-+-
 Reporter:  Finn Andersen|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  fk, gfk, generic | Triage Stage:  Accepted
  foreign key, validation|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_docs:  1 => 0
 * needs_tests:  1 => 0


Comment:

 We don't have a patch so there is no need to set this flags.

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

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

Re: [Django] #32939: Permit override_settings to work with test class mixins that don't inherit from unittest.TestCase

[Django]

#32939: Permit override_settings to work with test class mixins that don't 
inherit
from unittest.TestCase
--+
 Reporter:  Chris Jerdonek|Owner:  (none)
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  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 Chris Jerdonek):

 * owner:  Chris Jerdonek => (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/067.b39e1202bd280dec03e1b8be6b105095%40djangoproject.com.

Re: [Django] #32552: Allow DiscoverRunner to use a logger instead of printing to stdout

[Django]

#32552: Allow DiscoverRunner to use a logger instead of printing to stdout
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 |  Jerdonek
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  DiscoverRunner,print,logging,stdout,stderr|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Chris Jerdonek):

 * has_patch:  0 => 1


Comment:

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

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

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

Re: [Django] #33007: `form_clean()` performance

[Django]

#33007: `form_clean()` performance
--+
 Reporter:  David Smith   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Forms |  Version:  3.2
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Chris Jerdonek):

 > Thoughts?

 If a PR's purpose is to optimize, but it adds complexity (like adding
 caching), then it seems reasonable to me that there be an objective
 measure that people can look to that shows improvement. A related example:
 just in the last couple days, it was pointed out in
 [https://github.com/django/django/pull/14748 this PR] that
 `_lazy_re_compile()` (which was originally added as an optimization) was
 actually slower in one instance. How many more are like that?

 On the other hand, if a PR is doing something like removing a redundant
 operation or eliminating an unneeded argument, I think it should be okay
 even if a benchmark doesn't show a noticeable improvement. I know in some
 cases like that, the commit message wound up saying something like
 "Optimized ...," even if the impact might not really be noticeable. (I
 think a message like "Simplified ..." or "Removed redundant ..." might be
 more accurate in cases like that, so it doesn't overstate the impact.)

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

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

[Django] #33009: ./manage.py test --keepdb fails when DB permissions are not sufficient

[Django]

#33009: ./manage.py test --keepdb fails when DB permissions are not sufficient
-+-
   Reporter:  Jed|  Owner:  nobody
  Laundry|
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Background:

 - I'm using Django==3.1.13, and mssql-django==1.0
 - I have created Azure SQL Server, using Service Principal authentication,
 with two databases: **[db]** and **[test_db]**
 - the Service Principal has been configured with db_owner on both
 databases (i.e., `CREATE USER [app] FROM EXTERNAL PROVIDER; EXEC
 sp_addrolemember 'db_owner', [app];`)
 - I have updated DATABASES in settings.py with
 `Authentication=ActiveDirectoryServicePrincipal`

 I can use Django with no issues.

 However, when I run `./manage.py test --keepdb`, I get the following
 error:

 `pyodbc.InterfaceError: ('28000', "[28000] [Microsoft][ODBC Driver 17 for
 SQL Server][SQL Server]Login failed for user ''. (18456) (SQLDriverConnect)")`

 This is because the test runner first connects to **[dbo].[master]**,
 verifies **[test_db]** exists, and then reconnects to **[test_db]**.
 However, by default Service Principals do not have permission to access
 **[dbo].[master]** (and ideally shouldn't, when using the same server for
 multiple applications).

 This appears to be an intentional design decision to try connecting
 without the DB name even when using keepdb, as per
 django/db/backends/base/creation.py:50-55:

 {{{
 # We could skip this call if keepdb is True, but we instead
 # give it the keepdb param. This is to handle the case
 # where the test DB doesn't exist, in which case we need to
 # create it, then just not destroy it. If we instead skip
 # this, we will get an exception.
 self._create_test_db(verbosity, autoclobber, keepdb)
 }}}

 If I comment out this line, it works without issue.

 I'm happy to create a patch, but would like guidance on which is more
 acceptable fix:

 1. create a new flag, along the lines of "keepdb_dont_create", to skip
 _create_test_db
 2. reuse the keepdb flag, and only call _create_test_db if it is False
 3. put _create_test_db into a try: and except: pass, to avoid DB
 permission issues entirely

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

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

Re: [Django] #33004: Inconsistent / Unexpected handling of assigning unsaved model to Generic Foreign Key

[Django]

#33004: Inconsistent / Unexpected handling of assigning unsaved model to Generic
Foreign Key
-+-
 Reporter:  Finn Andersen|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  fk, gfk, generic | Triage Stage:  Accepted
  foreign key, validation|
Has patch:  0|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Finn Andersen):

 * needs_docs:  0 => 1
 * needs_tests:  0 => 1


Comment:

 I think verification should be done upon save() not assignment (to align
 with existing behaviour for FKs and enable saving of related model at
 later point before calling save() of primary model)

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

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

Re: [Django] #33007: `form_clean()` performance

[Django]

#33007: `form_clean()` performance
--+
 Reporter:  David Smith   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Forms |  Version:  3.2
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Simon Charette):

 * cc: Simon Charette (added)


Comment:

 While this particular commit was made to address a correctness issue the
 recent influx in optimization PRs merged in the past weeks made me wonder
 if we'd rather invest in having some form of CI to confirm their benefit
 in the grand scheme of things.

 I greatly appreciate having David run these benchmark from time to time
 but it'd be great to back optimization PRs with addition to the
 performance suite to make sure we don't trade one improvement for another
 over time. It would seem like a reasonable ask given how invested we are
 in writing regression tests for all bug fixes and feature additions?

 Thoughts? Maybe I should bring that up on the mailing list instead?

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

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

Re: [Django] #373: Add support for multiple-column primary keys

[Django]

#373: Add support for multiple-column primary keys
-+-
 Reporter:  Jacob|Owner:  Michael
 |  Schmidt
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  database | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Charlie Denton):

 * cc: Charlie Denton (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/063.2912c0f9c8877dac057ee95369288658%40djangoproject.com.

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

[Django]

#470: Add Field.db_default for defining database defaults
-+-
 Reporter:  jws  |Owner:  Ian Foote
 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 Charlie Denton):

 * cc: Charlie Denton (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/061.ebf6fad29cb90da12072d206c03d794b%40djangoproject.com.

[Django] #33008: prefetch_related for GenericForeignKey - Object doesn't exist behaviour

[Django]

#33008: prefetch_related for GenericForeignKey - Object doesn't exist behaviour
-+-
   Reporter:  Martin |  Owner:  nobody
  Svoboda|
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  3.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 prefetch_related called for GenericForeignKey sets content_type_id and
 object_id to None, if the foreign object doesn't exist. This behaviour is
 not documented.

 GenericForignKey is often used for audit records, so it can keep links to
 non-existing objects. Probably prefetch_related shouldn't touch original
 values of object_id and content_type_id and only set content_object to
 None.


 {{{
 from django.contrib.auth.models import User
 from django.contrib.contenttypes.fields import GenericForeignKey
 from django.contrib.contenttypes.models import ContentType
 from django.db import models


 class TaggedItem(models.Model):
 tag = models.SlugField()
 content_type = models.ForeignKey(ContentType,
 on_delete=models.CASCADE)
 object_id = models.PositiveIntegerField()
 content_object = GenericForeignKey('content_type', 'object_id')

 # init data
 guido = User.objects.create(username='Guido')
 t = TaggedItem(content_object=guido, tag='test')
 t.save()
 guido.delete()

 # get content_object normally
 tags_1 = TaggedItem.objects.filter(tag='test')
 tags_1[0].content_object  # returns None
 tags_1[0].object_id  # returns 1
 tags_1[0].content_type_id  # returns X

 # use prefetch_related
 tags_2 =
 TaggedItem.objects.filter(tag='test').prefetch_related("content_object")
 tags_2[0].content_object  # returns None
 tags_2[0].object_id  # returns None
 tags_2[0].content_type_id # returns None
 }}}

-- 
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/056.925bbf8c6cbeac611081b76312ca83e6%40djangoproject.com.

Re: [Django] #33007: `form_clean()` performance

[Django]

#33007: `form_clean()` performance
--+
 Reporter:  David Smith   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Forms |  Version:  3.2
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Chris Jerdonek):

 That ticket (#32920) was primarily about correctness rather than trying to
 do anything about performance. Nevertheless, one possible optimization
 that occurred to me while working on it was adding a flag to `BaseForm`
 called something like `self._bound_fields_cache_filled`. Then, the
 
[https://github.com/django/django/blob/b64db05b9cedd96905d637a2d824cbbf428e40e7/django/forms/forms.py#L147-L150
 BaseForm._bound_items()] and
 
[https://github.com/django/django/blob/b64db05b9cedd96905d637a2d824cbbf428e40e7/django/forms/forms.py#L152-L155
 BaseForm.__iter__()] iterators could consult that flag at their outset. If
 set, the `BoundField` items could be served directly from
 `_bound_fields_cache` instead of going through the extra layer of
 indirection of `BoundField.__getitem__()`. However, I don't know what's
 contributing most in terms of the slow-down. Maybe it's that
 `BoundField.initial`
 
[https://github.com/django/django/blob/b64db05b9cedd96905d637a2d824cbbf428e40e7/django/forms/boundfield.py#L228-L230
 uses @cached_property]?

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

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

Re: [Django] #33007: `form_clean()` performance

[Django]

#33007: `form_clean()` performance
--+
 Reporter:  David Smith   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Forms |  Version:  3.2
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Mariusz Felisiak):

 * cc: Chris Jerdonek (added)
 * type:  Uncategorized => Cleanup/optimization
 * component:  Uncategorized => Forms
 * stage:  Unreviewed => Accepted


Comment:

 Thanks! It's definitely worth investigating.

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

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

[Django] #33007: `form_clean()` performance

[Django]

#33007: `form_clean()` performance
-+
   Reporter:  David Smith|  Owner:  nobody
   Type:  Uncategorized  | 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  |
-+
 I ran the ran the benchmark suite to see if anything had changed in the
 last few months. See [https://smithdc1.github.io/django-
 asv/#forms.FormBenchmarks.time_form_clean link]

 This highlighted a regression (c.15% increase) in the performance
 `form_clean()` following this
 [https://github.com/django/django/commit/90a33ab2 commit], see
 [https://smithdc1.github.io/django-
 asv/#forms.FormBenchmarks.time_form_clean benchmark].

 I'm not certain what to suggest here, or if it's even that much of an
 issue and should be `wontfix`ed, but thought it best to atleast raise.

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

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

Re: [Django] #32341: forms.ModelMultipleChoiceField raises TypeError with empty_label argument.

[Django]

#32341: forms.ModelMultipleChoiceField raises TypeError with empty_label 
argument.
-+-
 Reporter:  thewamz  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  3.1
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
  ModelMultipleChoiceField   |  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:

 Please don't reopen closed ticket. This is not a bug,
 `ModelMultipleChoiceField` doesn't support `empty_label` (see
 
[https://docs.djangoproject.com/en/3.1/ref/forms/fields/#django.forms.ModelMultipleChoiceField
 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/065.d73b0dd9d7e7706d6ca97caa2c6f675a%40djangoproject.com.

Re: [Django] #32341: forms.ModelMultipleChoiceField raises TypeError with empty_label argument.

[Django]

#32341: forms.ModelMultipleChoiceField raises TypeError with empty_label 
argument.
-+-
 Reporter:  thewamz  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  ModelMultipleChoiceField   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by piscvau):

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


Comment:

 Hello
 In version 3.8 of module forms  line 1315 , The class
 ModelMultipleChoiceField.__init__ calls super().__init__ with empty_label
 = None. This a real bug easy to correct.

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

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

Re: [Django] #33006: 3.2.6 release isn't tagged

[Django]

#33006: 3.2.6 release isn't tagged
--+
 Reporter:  Jacob Walls   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Packaging |  Version:  3.2
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Carlton Gibson):

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


Comment:

 Thanks Jacob — I must have missed a `git push --tags` when rolling the
 last release.

 There now https://github.com/django/django/releases/tag/3.2.6

-- 
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/073.2235ee3fc9c1d8a90201cbe28a898cd2%40djangoproject.com.

Re: [Django] #26142: Provide a way for model formsets to disallow new object creation

[Django]

#26142: Provide a way for model formsets to disallow new object creation
-+
 Reporter:  Tim Graham   |Owner:  Vlad
 Type:  New feature  |   Status:  assigned
Component:  Forms|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+
Changes (by Vlad):

 * needs_better_patch:  1 => 0
 * needs_tests:  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/067.be8195f3b26e40b11d5187d784865f9c%40djangoproject.com.

[Django] #33006: 3.2.6 release isn't tagged

[Django]

#33006: 3.2.6 release isn't tagged
+
   Reporter:  Jacob Walls   |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Packaging |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 |
+
 There appears to be no `git tag` for 3.2.6. This is useful for checking
 out versions, e.g. `git checkout 3.2.6`.

-- 
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/058.b593266852c63ff7b1c8563cdc62645e%40djangoproject.com.

Re: [Django] #33002: Make DebugLexer.tokenize() more similar to Lexer.tokenize()

[Django]

#33002: Make DebugLexer.tokenize() more similar to Lexer.tokenize()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  closed
Component:  Template system  |  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


Comment:

 In [changeset:"f0776a558c4bee8524aa698c8dbe36790918152b" f0776a55]:
 {{{
 #!CommitTicketReference repository=""
 revision="f0776a558c4bee8524aa698c8dbe36790918152b"
 Fixed #33002 -- Made DebugLexer.tokenize() more closely parallel
 Lexer.tokenize().
 }}}

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

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

Re: [Django] #33002: Make DebugLexer.tokenize() more similar to Lexer.tokenize()

[Django]

#33002: Make DebugLexer.tokenize() more similar to Lexer.tokenize()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Template system  |  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:"b2be7e12cce8e62512fbea4a32503d048120" b2be7e1]:
 {{{
 #!CommitTicketReference repository=""
 revision="b2be7e12cce8e62512fbea4a32503d048120"
 Refs #33002 -- Made template_tests.tests.py's tests test both Lexer and
 DebugLexer.
 }}}

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

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

Re: [Django] #33002: Make DebugLexer.tokenize() more similar to Lexer.tokenize()

[Django]

#33002: Make DebugLexer.tokenize() more similar to Lexer.tokenize()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Template system  |  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:"6fedd868e1d50421204ea0c05cc8d2200dcb3cb0" 6fedd868]:
 {{{
 #!CommitTicketReference repository=""
 revision="6fedd868e1d50421204ea0c05cc8d2200dcb3cb0"
 Refs #33002 -- Renamed variable from bit to token_string in
 Lexer.tokenize().
 }}}

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

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

Re: [Django] #33002: Make DebugLexer.tokenize() more similar to Lexer.tokenize()

[Django]

#33002: Make DebugLexer.tokenize() more similar to Lexer.tokenize()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Template system  |  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:"6242c22a2f062f1b55f8a612b75063966937bc5d" 6242c22]:
 {{{
 #!CommitTicketReference repository=""
 revision="6242c22a2f062f1b55f8a612b75063966937bc5d"
 Refs #33002 -- Optimized Lexer.tokenize() by skipping computing lineno
 when not needed.
 }}}

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

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

Re: [Django] #33002: Make DebugLexer.tokenize() more similar to Lexer.tokenize()

[Django]

#33002: Make DebugLexer.tokenize() more similar to Lexer.tokenize()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Template system  |  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:"65ed96fa394f3d9d548c6d9d8144bbb51c4c68ff" 65ed96fa]:
 {{{
 #!CommitTicketReference repository=""
 revision="65ed96fa394f3d9d548c6d9d8144bbb51c4c68ff"
 Refs #33002 -- Added DebugLexer/Lexer.tokenize() test for trailing text
 token.
 }}}

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

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

Re: [Django] #33003: Micro-optimisation for QuerySet._chain

[Django]

#33003: Micro-optimisation for QuerySet._chain
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 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 GitHub ):

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


Comment:

 In [changeset:"921e4ccb77ed2056d5cdfc6756ee82b54831937f" 921e4cc]:
 {{{
 #!CommitTicketReference repository=""
 revision="921e4ccb77ed2056d5cdfc6756ee82b54831937f"
 Fixed #33003 -- Removed **kwargs from QuerySet._chain().

 The functionality of updating the __dict__ was only present to allow
 for pickling a Prefetch object, which is a comparably rare operation.
 Forcing the __getstate__() implementation to handle it allows the
 chaining operation to be slightly faster, which is much more common.
 }}}

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

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

Re: [Django] #33004: Inconsistent / Unexpected handling of assigning unsaved model to Generic Foreign Key

[Django]

#33004: Inconsistent / Unexpected handling of assigning unsaved model to Generic
Foreign Key
-+-
 Reporter:  Finn Andersen|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  fk, gfk, generic | Triage Stage:  Accepted
  foreign key, validation|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * type:  Cleanup/optimization => Bug


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

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

Re: [Django] #33004: Inconsistent / Unexpected handling of assigning unsaved model to Generic Foreign Key

[Django]

#33004: Inconsistent / Unexpected handling of assigning unsaved model to Generic
Foreign Key
-+-
 Reporter:  Finn Andersen|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  fk, gfk, generic | Triage Stage:  Accepted
  foreign key, validation|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * cc: Tim Graham (added)
 * stage:  Unreviewed => Accepted


Comment:

 Agreed, assigning unsaved objects should raise an error for
 `GenericForeignKey`. It was added in
 5643a3b51be338196d0b292d5626ad43648448d3 but reverted later in
 5980b05c1fad69eef907e0076aa2dc837edab529. It looks like an unintended
 change as [https://docs.djangoproject.com/en/stable/releases/1.8
 /#assigning-unsaved-objects-to-relations-raises-an-error release notes]
 still claim that an error is raised in this case.

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

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

Re: [Django] #33003: Micro-optimisation for QuerySet._chain

[Django]

#33003: Micro-optimisation for QuerySet._chain
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 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/067.cef9996416b9b9074e915a527516ed5f%40djangoproject.com.

Re: [Django] #32999: Admin Tabular Stacked Inline widget headings are not aligned headings

[Django]

#32999: Admin Tabular Stacked Inline widget headings are not aligned headings
-+-
 Reporter:  Michael  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  contrib.admin|  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  tabularinline css| Triage Stage:
  style styling  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Description changed by Michael:

Old description:

> [[Image(https://code.djangoproject.com/attachment/ticket/32999/notaligned.png)]]
>
> With the following model:
>
> {{{
> class ApplicantAdmin(admin.TabularInline):
> model = Application.applicant_set.through
>
> @admin.register(Application)
> class ApplicationAdmin(admin.ModelAdmin):
> exclude = ('applicant_set', )
> inlines = (ApplicantAdmin, )
>
> }}}
>
> The heading `Delete?` is on the left, however the delete button is on the
> right, making it confusing for some people.

New description:

 [[https://code.djangoproject.com/attachment/ticket/32999/inline%20tabular.png]]

 With the following model:

 {{{
 class ApplicantAdmin(admin.TabularInline):
 model = Application.applicant_set.through

 @admin.register(Application)
 class ApplicationAdmin(admin.ModelAdmin):
 exclude = ('applicant_set', )
 inlines = (ApplicantAdmin, )

 }}}

 The heading `Delete?` is on the left, however the delete button is on the
 right, making it confusing for some people.

 Another issue is if the stacktabular has many fields:
 Instead of the stacked tabular getting overflow x scroll, the whole page
 does:
 [[https://code.djangoproject.com/attachment/ticket/32999/notaligned.png]]

--

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

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

Re: [Django] #32999: Admin Tabular Stacked Inline widget headings are not aligned headings

[Django]

#32999: Admin Tabular Stacked Inline widget headings are not aligned headings
-+-
 Reporter:  Michael  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  contrib.admin|  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  tabularinline css| Triage Stage:
  style styling  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Michael):

 * Attachment "inline tabular.png" added.

 If it is quite wide

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

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

Re: [Django] #33002: Make DebugLexer.tokenize() more similar to Lexer.tokenize()

[Django]

#33002: Make DebugLexer.tokenize() more similar to Lexer.tokenize()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Template system  |  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/067.bb806891c5d7095e9b73216ba95fe56e%40djangoproject.com.

Re: [Django] #32990: Test the tag_re regex in template/base.py instead of evaluating it every time

[Django]

#32990: Test the tag_re regex in template/base.py instead of evaluating it every
time
-+-
 Reporter:  Chris Jerdonek   |Owner:  gtwohig
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Template system  |  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:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"c99aaf14eef2a18b27bc7c2f2b17ae425ca2be49" c99aaf14]:
 {{{
 #!CommitTicketReference repository=""
 revision="c99aaf14eef2a18b27bc7c2f2b17ae425ca2be49"
 Refs #32990 -- Added tests for DebugLexer/Lexer.tokenize().
 }}}

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

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

Re: [Django] #32990: Test the tag_re regex in template/base.py instead of evaluating it every time

[Django]

#32990: Test the tag_re regex in template/base.py instead of evaluating it every
time
-+-
 Reporter:  Chris Jerdonek   |Owner:  gtwohig
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Template system  |  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:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"fc2bd40fc76996306efc1f8de581708d8c5a2943" fc2bd40f]:
 {{{
 #!CommitTicketReference repository=""
 revision="fc2bd40fc76996306efc1f8de581708d8c5a2943"
 Fixed #32990 -- Simplified and optimized tag regex.

 Thanks Chris Jerdonek for the review.
 }}}

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

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