Re: [Django] #32243: Clarify docs on manually setting and saving a FileField.

[Django]

#32243: Clarify docs on manually setting and saving a FileField.
-+-
 Reporter:  Gordon Wrigley   |Owner:  Joshua
 Type:   |  Massover
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1


Comment:

 See [https://github.com/django/django/pull/15245#issuecomment-1002670888
 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/065.aa08d0c6ac58b0a796354e3c927237bb%40djangoproject.com.

Re: [Django] #33300: Hidden fields are visible on small screens.

[Django]

#33300: Hidden fields are visible on small screens.
-+-
 Reporter:  Maxim Danilov|Owner:  Shubh
 |  Parmar
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  4.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  admin, modeladmin,   | Triage Stage:  Ready for
  css|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"aecfc40c88ce19aa0b830ee2d3d2077b304757bc" aecfc40c]:
 {{{
 #!CommitTicketReference repository=""
 revision="aecfc40c88ce19aa0b830ee2d3d2077b304757bc"
 Fixed #33300 -- Ensured hidden elements are not displayed on small
 screens.
 }}}

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

Re: [Django] #23273: MigrationRecorder does not obey db_router allow_migrate rules

[Django]

#23273: MigrationRecorder does not obey db_router allow_migrate rules
+-
 Reporter:  froomzy |Owner:  Jacob Walls
 Type:  Bug |   Status:  closed
Component:  Migrations  |  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:"92412aa94c97b5c36387fadb39d9f8edf25547fa" 92412aa]:
 {{{
 #!CommitTicketReference repository=""
 revision="92412aa94c97b5c36387fadb39d9f8edf25547fa"
 Fixed #23273 -- Avoided creation of django_migrations table when there are
 no migrations to apply.
 }}}

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

Re: [Django] #33399: Overriding Choices for a field in the Form not working when using ModelForm. (was: Overriding Choices for a field in the Form not working when using ModelForm | Django 3.2)

[Django]

#33399: Overriding Choices for a field in the Form not working when using
ModelForm.
---+--
 Reporter:  Swaroop P  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Forms  |  Version:  3.0
 Severity:  Normal |   Resolution:  invalid
 Keywords:  modelform  | 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
 * version:  3.2 => 3.0
 * resolution:   => invalid


Comment:

 Thanks for the report, it was changed in
 16a5a2a2c8d8dbf9cc3e033dd84b986bcaadb963, however it's
 
[https://docs.djangoproject.com/en/4.0/ref/models/fields/#django.db.models.Field.choices
 documented] that:

 > ''For **each model field that has `choices` set**, Django will add a
 method to retrieve the human-readable name for the field’s current value.
 See `get_FOO_display()` in the database API documentation.''
 >
 > ''Note that choices can be any sequence object – not necessarily a list
 or tuple. This lets you construct choices dynamically. But if you find
 yourself hacking choices to be dynamic, you’re probably better off using a
 proper database table with a `ForeignKey`. `choices` **is meant for static
 data that doesn’t change much, if ever.'**'

 `choices=[]` means that it's set, if you want to get the previous behavior
 without any validation you shouldn't define `choices` on a model field, or
 set `choices=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/069.1c413425e09a5747404b76a80c26dd14%40djangoproject.com.

Re: [Django] #33399: Overriding Choices for a field in the Form not working when using ModelForm | Django 3.2

[Django]

#33399: Overriding Choices for a field in the Form not working when using 
ModelForm
| Django 3.2
---+--
 Reporter:  Swaroop P  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Forms  |  Version:  3.2
 Severity:  Normal |   Resolution:
 Keywords:  modelform  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Swaroop P):

 * version:  3.0 => 3.2


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

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

Re: [Django] #33399: Overriding Choices for a field in the Form not working when using ModelForm | Django 3.2

[Django]

#33399: Overriding Choices for a field in the Form not working when using 
ModelForm
| Django 3.2
---+--
 Reporter:  Swaroop P  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Forms  |  Version:  3.0
 Severity:  Normal |   Resolution:
 Keywords:  modelform  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Description changed by Swaroop P:

Old description:

> Hi All
>
> Facing the following issue after migrating to 3.2.
>
> Example:
> {{{
>
> class SomeModel(models.Model):
>field1 = models.CharField(choices=[])
>
> class SomeModelForm(forms.ModelForm):
>
>  __init__(*args, **kwargs):
>  super().__init__(*args **kwargs)
>  self.fields['field1'] = 
>
> class Meta:
>  model = SomeModel
>  fields = [ 'field1' ]
> }}}
>

> In the above case any choice selected is shown with the error "not a
> valid choice" this is happening because model fields is revalidated again
> in modelform._post_clean() function.
>
> Intermediate solution is to remove choices from modelfield and
> reinitalize field in form __init__ wiht dynamic choices. But In previous
> versions We had choices to only override some attributes of a field
> rather than reinitalizing whole field.
>
> Thanks

New description:

 Hi All

 Facing the following issue after migrating to 3.2.

 Example:
 {{{

 class SomeModel(models.Model):
field1 = models.CharField(choices=[])

 class SomeModelForm(forms.ModelForm):

  __init__(*args, **kwargs):
  super().__init__(*args **kwargs)
  self.fields['field1'].choices = 

 class Meta:
  model = SomeModel
  fields = [ 'field1' ]
 }}}


 In the above case any choice selected is shown with the error "not a valid
 choice" this is happening because model fields is revalidated again  in
 modelform._post_clean() function.

 Intermediate solution is to remove choices from modelfield and reinitalize
 field in form __init__ wiht dynamic choices. But In previous versions We
 had choices to only override some attributes of a field rather than
 reinitalizing whole field.

 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/069.815cfa17ee41eac9994bbb4d54298b3c%40djangoproject.com.

Re: [Django] #33399: Overriding Choices for a field in the Form not working when using ModelForm | Django 3.2

[Django]

#33399: Overriding Choices for a field in the Form not working when using 
ModelForm
| Django 3.2
---+--
 Reporter:  Swaroop P  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Forms  |  Version:  3.0
 Severity:  Normal |   Resolution:
 Keywords:  modelform  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Description changed by Swaroop P:

Old description:

> Hi All
>
> Facing the following issue after migrating to 3.2.
>
> Example:
>
> class SomeModel(models.Model):
>field1 = models.CharField(choices=[])
>
> class SomeModelForm(forms.ModelForm):
>
>  __init__(*args, **kwargs):
>  super().__init__(*args **kwargs)
>  self.fields['field1'] = 
>
> class Meta:
>  model = SomeModel
>  fields = [ 'field1' ]
>

> In the above case any choice selected is shown with the error "not a
> valid choice" this is happening because model fields is revalidated again
> in modelform._post_clean() function.
>
> Intermediate solution is to remove choices from modelfield and
> reinitalize field in form __init__ wiht dynamic choices. But In previous
> versions We had choices to only override some attributes of a field
> rather than reinitalizing whole field.
>
> Thanks

New description:

 Hi All

 Facing the following issue after migrating to 3.2.

 Example:
 {{{

 class SomeModel(models.Model):
field1 = models.CharField(choices=[])

 class SomeModelForm(forms.ModelForm):

  __init__(*args, **kwargs):
  super().__init__(*args **kwargs)
  self.fields['field1'] = 

 class Meta:
  model = SomeModel
  fields = [ 'field1' ]
 }}}


 In the above case any choice selected is shown with the error "not a valid
 choice" this is happening because model fields is revalidated again  in
 modelform._post_clean() function.

 Intermediate solution is to remove choices from modelfield and reinitalize
 field in form __init__ wiht dynamic choices. But In previous versions We
 had choices to only override some attributes of a field rather than
 reinitalizing whole field.

 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/069.76677f7e09539527631f0f2b4667cd24%40djangoproject.com.

[Django] #33399: Overriding Choices for a field in the Form not working when using ModelForm | Django 3.2

[Django]

#33399: Overriding Choices for a field in the Form not working when using 
ModelForm
| Django 3.2
-+---
   Reporter:  Swaroop P  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Forms  |Version:  3.0
   Severity:  Normal |   Keywords:  modelform
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+---
 Hi All

 Facing the following issue after migrating to 3.2.

 Example:

 class SomeModel(models.Model):
field1 = models.CharField(choices=[])

 class SomeModelForm(forms.ModelForm):

  __init__(*args, **kwargs):
  super().__init__(*args **kwargs)
  self.fields['field1'] = 

 class Meta:
  model = SomeModel
  fields = [ 'field1' ]


 In the above case any choice selected is shown with the error "not a valid
 choice" this is happening because model fields is revalidated again  in
 modelform._post_clean() function.

 Intermediate solution is to remove choices from modelfield and reinitalize
 field in form __init__ wiht dynamic choices. But In previous versions We
 had choices to only override some attributes of a field rather than
 reinitalizing whole field.

 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/054.532716b51a5d3c4d32994d64ed16536b%40djangoproject.com.

Re: [Django] #33300: Hidden fields are visible on small screens.

[Django]

#33300: Hidden fields are visible on small screens.
-+-
 Reporter:  Maxim Danilov|Owner:  Shubh
 |  Parmar
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  admin, modeladmin,   | Triage Stage:  Ready for
  css|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
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/067.c3c7a605b62aed5b47355dcd75c523f8%40djangoproject.com.

Re: [Django] #23273: MigrationRecorder does not obey db_router allow_migrate rules

[Django]

#23273: MigrationRecorder does not obey db_router allow_migrate rules
+-
 Reporter:  froomzy |Owner:  Jacob Walls
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  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/065.08766673761cd74b703e16e8bd676e78%40djangoproject.com.

Re: [Django] #33398: ModelAdmin.empty_value_display example in docs should use list_display. (was: ModelAdmin.empty_value_display documentation)

[Django]

#33398: ModelAdmin.empty_value_display example in docs should use list_display.
--+
 Reporter:  Michael   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  4.0
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Mariusz Felisiak):

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


Comment:

 > I think this will only work for the list display, not setting the empty
 value of the field during edit view.

 It also works for `readonly_fields`, but I agree that `list_display` fits
 better here. Would you like to provide 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/068.3a03d91bfbc9d7add9f76d79660a2242%40djangoproject.com.

Re: [Django] #33256: Some schema tests don't clean up their tables

[Django]

#33256: Some schema tests don't clean up their tables
-+-
 Reporter:  Tim Graham   |Owner:  banani720
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 Replying to [comment:5 Ayush Joshi]:
 > When I run this command I don't know why but I'm getting the following
 {{{ModuleNotFoundError}}}, could you please help?

 `--settings` should be a path to your `settings` (see
 [https://docs.djangoproject.com/en/4.0/internals/contributing/writing-code
 /unit-tests/#using-another-settings-module docs]) not a test module. If
 you're having trouble understanding how Django works, see
 TicketClosingReasons/UseSupportChannels for ways to get help.

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

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

Re: [Django] #33256: Some schema tests don't clean up their tables

[Django]

#33256: Some schema tests don't clean up their tables
-+-
 Reporter:  Tim Graham   |Owner:  banani720
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Ayush Joshi):

 Replying to [comment:4 Mariusz Felisiak]:
 > > If I have not done all of the cases yet, but just want to check in to
 see if I am going about this the correct way, should I still submit a pr?
 >
 > I don't think there is a need to submit PR at this stage. You should be
 able to [https://docs.djangoproject.com/en/3.2/internals/contributing
 /writing-code/unit-tests/ run tests locally] and check that all `schema`
 tests work:
 > {{{
 > ./runtests.py --settings=test_postgres --parallel=1 --keepdb schema
 > }}}
 > I'd submit PR when all test pass.

 When I run this command I don't know why but I'm getting the following
 {{{ModuleNotFoundError}}}, could you please help?

 {{{
 Testing against Django installed in '/Python/django/django'
 Traceback (most recent call last):
   File "./runtests.py", line 657, in 
 failures = django_tests(
   File "./runtests.py", line 348, in django_tests
 test_labels, state = setup_run_tests(verbosity, start_at, start_after,
 test_labels)
   File "./runtests.py", line 278, in setup_run_tests
 test_modules, state = setup_collect_tests(start_at, start_after,
 test_labels=test_labels)
   File "./runtests.py", line 193, in setup_collect_tests
 'INSTALLED_APPS': settings.INSTALLED_APPS,
   File "/Python/django/django/conf/__init__.py", line 89, in __getattr__
 self._setup(name)
   File "/Python/django/django/conf/__init__.py", line 76, in _setup
 self._wrapped = Settings(settings_module)
   File "/Python/django/django/conf/__init__.py", line 184, in __init__
 mod = importlib.import_module(self.SETTINGS_MODULE)
   File "/usr/lib/python3.8/importlib/__init__.py", line 127, in
 import_module
 return _bootstrap._gcd_import(name[level:], package, level)
   File "", line 1014, in _gcd_import
   File "", line 991, in _find_and_load
   File "", line 973, in
 _find_and_load_unlocked
 ModuleNotFoundError: No module named 'test_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/067.20dddcba0f614a5e522931b5d889cdb3%40djangoproject.com.

[Django] #33398: ModelAdmin.empty_value_display documentation

[Django]

#33398: ModelAdmin.empty_value_display documentation
-+
   Reporter:  Michael|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Documentation  |Version:  4.0
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+
 Firstly, the documentation is great. In the
 
[https://docs.djangoproject.com/en/4.0/ref/contrib/admin/#django.contrib.admin.ModelAdmin.empty_value_display
 admin site docs], it has this example:

 {{{
 from django.contrib import admin

 class AuthorAdmin(admin.ModelAdmin):
 fields = ('name', 'title', 'view_birth_date')

 @admin.display(empty_value='???')
 def view_birth_date(self, obj):
 return obj.birth_date]
 }}}

 I think this will only work for the list display, not setting the empty
 value of the field during edit view.
 Hence I think
 {{{
 fields = ('name', 'title', 'view_birth_date')
 }}}
 should become
 {{{
 list_display = ('name', 'title', 'view_birth_date')
 }}}

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

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

Re: [Django] #33397: Arithmetic operations on DateField/DateTimeField/DurationField expressions are buggy.

[Django]

#33397: Arithmetic operations on DateField/DateTimeField/DurationField 
expressions
are buggy.
-+-
 Reporter:  Luke Plant   |Owner:  Luke
 |  Plant
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Luke Plant):

 For anyone else looking at this:

 The underlying behaviour of `BaseExpression._resolve_output_field` is an
 enormous can of worms, especially once you dig into database differences,
 tickets #26650, #31506 and preserving compatibility with existing
 behaviour.

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

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

Re: [Django] #31335: Renaming a ForeignKey included in an index, and removing UniqueConstraint, Index with ForeignKey fails on MySQL.

[Django]

#31335: Renaming a ForeignKey included in an index, and removing 
UniqueConstraint,
Index with ForeignKey fails on MySQL.
-+-
 Reporter:  Stephen Finucane |Owner:  Sergey
 |  Fursov
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  3.0
 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 Jacob Walls):

 * owner:  Sanskar Jaiswal => Sergey Fursov
 * needs_tests:  1 => 0


Comment:

 [https://github.com/django/django/pull/15254 PR]

 Not completely certain yet if the PR addresses the entirety of the
 comments on this thread, but just linking to increase visibility.

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

[Django] #33397: Arithmetic operations on DateField/DateTimeField/DurationField expressions are buggy.

[Django]

#33397: Arithmetic operations on DateField/DateTimeField/DurationField 
expressions
are buggy.
-+-
   Reporter:  Luke   |  Owner:  Luke Plant
  Plant  |
   Type:  Bug| Status:  assigned
  Component:  Database   |Version:  4.0
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 There are two main sets of bugs here:

 1. Nonsensical operations involving `DateField` or `DateTimeField`
 expressions (such as adding two dates) do not raise the expected
 `FieldError` exceptions. They usually raise exceptions later that vary
 depending on the database backend.

 2. Well-defined operations, which work in SQL, such as ’date + duration’,
 require using `ExpressionWrapper(output_field=…)` when this could be
 inferred.


 Although we could technically split this into two bugs, I’m filing as one
 since the two parts are closely related and fixing part 2 (which is the
 real reason I’m
 here) will require some changes that impinge on part 1.

 == Part 1

 Test case

 {{{#!python
 # tests/experiments/tests.py

 class FTimeDeltaTests(TestCase):
 def test_nonsensical_date_operations(self):
 queryset = Experiment.objects.annotate(nonsense=F('name') +
 F('assigned'))
 with self.assertRaises(FieldError):
 list(queryset)

 queryset = Experiment.objects.annotate(nonsense=F('assigned') +
 F('completed'))
 with self.assertRaises(FieldError):
 list(queryset)
 }}}


 The first part works as expected (it makes no sense to add a string to a
 date, and a `FieldError` is raised), but the second doesn’t.

 Expected behaviour: `FieldError` should be raised

 Actual behaviour:

 With Postgres:

 {{{
   File "/home/luke/devel/django/main/django/db/models/query.py", line 51,
 in __iter__
 results = compiler.execute_sql(chunked_fetch=self.chunked_fetch,
 chunk_size=self.chunk_size)
   File "/home/luke/devel/django/main/django/db/models/sql/compiler.py",
 line 1211, in execute_sql
 cursor.execute(sql, params)
   File "/home/luke/devel/django/main/django/db/backends/utils.py", line
 67, in execute
 return self._execute_with_wrappers(sql, params, many=False,
 executor=self._execute)
   File "/home/luke/devel/django/main/django/db/backends/utils.py", line
 76, in _execute_with_wrappers
 return executor(sql, params, many, context)
   File "/home/luke/devel/django/main/django/db/backends/utils.py", line
 85, in _execute
 return self.cursor.execute(sql, params)
   File "/home/luke/devel/django/main/django/db/utils.py", line 90, in
 __exit__
 raise dj_exc_value.with_traceback(traceback) from exc_value
   File "/home/luke/devel/django/main/django/db/backends/utils.py", line
 85, in _execute
 return self.cursor.execute(sql, params)
 psycopg2.errors.UndefinedFunction: operator does not exist: date + date
 LINE 1: ...t"."scalar", ("expressions_ExPeRiMeNt"."assigned" + "express...
  ^
 HINT:  No operator matches the given name and argument types. You might
 need to add explicit type casts.
 }}}

 With SQLite:
 {{{
   File "/home/luke/devel/django/main/django/db/models/query.py", line 68,
 in __iter__
 for row in compiler.results_iter(results):
   File "/home/luke/devel/django/main/django/db/models/sql/compiler.py",
 line 1158, in apply_converters
 value = converter(value, expression, connection)
   File
 "/home/luke/devel/django/main/django/db/backends/sqlite3/operations.py",
 line 305, in convert_datefield_value
 value = parse_date(value)
   File "/home/luke/devel/django/main/django/utils/dateparse.py", line 76,
 in parse_date
 return datetime.date.fromisoformat(value)
 TypeError: fromisoformat: argument must be str

 }}}
 I have not tested on other databases.

 === Additional notes

 There is a related bug in some context. For example, in contrast to the
 above test case `Experiment.objects.filter(name=F('name') +
 F('assigned'))` does not raise `FieldError`, despite the attempt to add a
 date to a string. Instead you get backend dependent results - SQLite
 silently does some type coercion, Postgres fails with `UndefinedFunction`.
 Tackling this may need to be done separately - there are different code
 paths involved when using `QuerySet.annotate()` compared to
 `QuerySet.filter()`


 == Part 2

 Test case:

 {{{#!python
 # tests/experiments/tests.py

 class FTimeDeltaTests(TestCase):
 def
 test_datetime_and_duration_field_addition_without_output_field

Re: [Django] #33396: Add the ResolverMatch's name to the technical 500 page.

[Django]

#33396: Add the ResolverMatch's name to the technical 500 page.
-+
 Reporter:  Keryn Knight |Owner:  Keryn Knight
 Type:  New feature  |   Status:  assigned
Component:  Error reporting  |  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 Keryn Knight):

 * owner:  (none) => Keryn Knight
 * status:  new => assigned


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

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

Re: [Django] #33396: Add the ResolverMatch's name to the technical 500 page.

[Django]

#33396: Add the ResolverMatch's name to the technical 500 page.
-+
 Reporter:  Keryn Knight |Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Error reporting  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Mariusz Felisiak):

 * stage:  Unreviewed => Accepted


Comment:

 Sounds reasonable.

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

[Django] #33396: Add the ResolverMatch's name to the technical 500 page.

[Django]

#33396: Add the ResolverMatch's name to the technical 500 page.
---+
   Reporter:  Keryn Knight |  Owner:  (none)
   Type:  New feature  | Status:  new
  Component:  Error reporting  |Version:  dev
   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|
---+
 Way back when in #22756, I asked for and was given a lovely addition to
 the **technical 404 page**, so that when `raise Http404('...')` was used
 it would report the view being executed, so that coming back to a project
 and getting an error would give me a hint where to look.

 It looks like this, give or take alignment:
 {{{
 Request Method: GET
 Request URL:http://localhost:8080/egsdh
 Raised by:  __main__.ItemDetail
 }}}

 Today I'm here to ask for the same in the **technical 500 page**.
 I just opened a project from ''about 3 weeks ago'' and in that short time
 had apparently forgotten what views were mounted on what URLs, and however
 many years after that ticket, Django still doesn't have a management
 command for printing me the URLs (... sigh), so I had to go digging again
 to deal with the error I'd evidently left myself.

 `django.views.debug.ExceptionReporter.get_traceback_data` already has
 awareness of the request (`if self.request is not None`) which it uses to
 print the GET/POST/etc. I'd like to suggest that within that block, we do
 something like:

 {{{
 if self.request is not None:
 try:
 view_name = self.request.resolver_match._func_path
 except Exception:
 view_name = None
 c['view_name'] = view_name
 }}}

 and then adjust the template to have a `Raised by: {{ view_name }}` line
 as the technical 404 page, guarding it with an `{% if %}` test. We might
 want to change the label from `Raised by` across both to something like
 `Raised during` or `During View` or something ...

 The 500 page might thus look something like:
 {{{
 Request Method: GET
 Request URL:http://localhost:8080/
 View name:  __main__.ItemList
 Django Version: 4.x.x
 Exception Type: ZeroDivisionError
 Exception Value:division by zero
 ...
 }}}

 By the look of it, the code for the technical 404 page and the
 ResolverMatch name may ''mostly'' overlap in terms of calculation/output,
 except:
 - #32260 was relatively recently patched into the 404 page, so that
 references `.view_class`
 - `ResolverMatch` is separately ''aware'' that the `func` might be a
 `functools.partial`, but only within the `__repr__`
 So it's possible there could be some tidying up/DRY aside from those
 edges.

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

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

Re: [Django] #27936: Add some clarifications to "Spanning multi-valued relationships"

[Django]

#27936: Add some clarifications to "Spanning multi-valued relationships"
-+-
 Reporter:  Thomas Güttler   |Owner:  Jacob
 Type:   |  Walls
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  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/065.e9087f2dee7183c6142cce086847f0b4%40djangoproject.com.

Re: [Django] #33394: Adding inlines doesn't work with a manually crafted HTML.

[Django]

#33394: Adding inlines doesn't work with a manually crafted HTML.
-+-
 Reporter:  Maxim Danilov|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  4.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  admin, modeladmin,   | Triage Stage:
  inline, inline.js  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 Because, as far as I'm aware it's not a supported scenario. If you can
 provide a sample project that reproduces this issue without steps based on
 manual modification of the generated HTML, then we can reconsider this
 decision.

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

Re: [Django] #33394: Adding inlines doesn't work with a manually crafted HTML.

[Django]

#33394: Adding inlines doesn't work with a manually crafted HTML.
-+-
 Reporter:  Maxim Danilov|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  admin, modeladmin,   | Triage Stage:
  inline, inline.js  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Maxim Danilov):

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


Comment:

 inline.js has a bug: document.onready add link to wrong html tag.
 It can be reproduced, and it has patch.

 Why it should be not changed?

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

Re: [Django] #33395: No error raised when FILE_UPLOAD_TEMP_DIR is not accessible

[Django]

#33395: No error raised when FILE_UPLOAD_TEMP_DIR is not accessible
-+-
 Reporter:  Martin Koščak|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  3.2
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  empty request large  | Triage Stage:
  file upload|  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
 * component:  File uploads/storage => Core (Other)
 * type:  Uncategorized => Bug


Comment:

 Thanks for the report. It should be fixed in Django 4.0, see #32329,
 #32360, and related commits 00ea883ef56fb5e092cbe4a6f7ff2e7470886ac4 and
 b1821fbad5518c8ae56b7b5c2b1ea2afbbd25c7a.

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

[Django] #33395: No error raised when FILE_UPLOAD_TEMP_DIR is not accessible

[Django]

#33395: No error raised when FILE_UPLOAD_TEMP_DIR is not accessible
-+-
   Reporter:  Martin |  Owner:  nobody
  Koščak |
   Type: | Status:  new
  Uncategorized  |
  Component:  File   |Version:  3.2
  uploads/storage|   Keywords:  empty request large
   Severity:  Normal |  file upload
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 This one took me a while to figure out, so I'm creating a ticket.
 The initial issue I had was, when I uploaded a larger file (+10MB), I
 received no data in request. The POST, GET and FILES attributes of request
 were all empty, only META attribute was OK.

 After a lot of digging I've found the root of my problem. I had invalid
 ownership set on FILE_UPLOAD_TEMP_DIR.
 Once the file exceeded FILE_UPLOAD_MAX_MEMORY_SIZE and was deemed as
 TemporaryUploadedFile, something happened, and I received an empty
 request.

 This could be solved much sooner, if an Exception was raised.
 This happened in production environment with Apache and WSGI.

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

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

Re: [Django] #26872: Django Admin filter choice list can overflow the whole page

[Django]

#26872: Django Admin filter choice list can overflow the whole page
---+
 Reporter:  Damien |Owner:  Kenneth
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.9
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  1  |UI/UX:  1
---+

Comment (by GitHub ):

 In [changeset:"361bb8f786f112ee275be136795c0b1ecefff928" 361bb8f7]:
 {{{
 #!CommitTicketReference repository=""
 revision="361bb8f786f112ee275be136795c0b1ecefff928"
 Refs #26872 -- Fixed wrapping of long choices in ModelAdmin.list_filter.

 Regression in 269a76714616fd7ad166a14113f3354bab8d9b65.
 }}}

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

Re: [Django] #33394: Adding inlines doesn't work with a manually crafted HTML. (was: inlines.js error in django.contrib.admin since Django 1.xx)

[Django]

#33394: Adding inlines doesn't work with a manually crafted HTML.
-+-
 Reporter:  Maxim Danilov|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  4.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  admin, modeladmin,   | Triage Stage:
  inline, inline.js  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * status:  new => closed
 * type:  Bug => Cleanup/optimization
 * has_patch:  1 => 0
 * resolution:   => invalid


Comment:

 > This is not impossible situation, i include additional inline for my
 needs directly in html, and founded this bug.

 Thanks for the report, however I don't think it's something that we would
 like (or need) to support.

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

Re: [Django] #33393: Weird title level in logging how-to

[Django]

#33393: Weird title level in logging how-to
-+-
 Reporter:  Claude Paroz |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  4.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 `h5` styling was missing, see
 https://github.com/django/djangoproject.com/pull/1135.

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

[Django] #33394: inlines.js error in django.contrib.admin since Django 1.xx

[Django]

#33394: inlines.js error in django.contrib.admin since Django 1.xx
-+-
   Reporter:  Maxim  |  Owner:  nobody
  Danilov|
   Type:  Bug| Status:  new
  Component: |Version:  4.0
  contrib.admin  |   Keywords:  admin, modeladmin,
   Severity:  Normal |  inline, inline.js
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 We have a very old bug in inlines.js from
 django\contrib\admin\static\admin\js.

 error in  inlines.js from row 327, method document.onready

 How to reproduce:
 1. Create admin form with any inline.
 2. Open change form in browser, сopy whole html tag with class=".js-
 inline-admin-formset" and with childs.
 3. Override admin/change_form.html and add copy html part from 2. before
 admin form. Of cause all "id" in tags should be unique.

 Now every time if change_form is opened,  inlines.js made wrong
 add_new_inline_object link.

 Why:
 in inlines.js any methods stackedFormset or tabularFormset don't check
 "id" from formset and add link to any formset with childs with class
 "...-group" and  ".inline-related".

 Has Patch: yes.

 {{{
 //  django\contrib\admin\static\admin\js\inlines.js
 // row 335:
 $(selector).stackedFormset(selector, inlineOptions.options);
 // change to
 $(this).find("[id^=" + inlineOptions.name.substring(1) +
 "-]").stackedFormset(selector, inlineOptions.options);

 // rows 338-339:
 selector = inlineOptions.name + "-group .tabular.inline-related
 tbody:first > tr.form-row";
 $(selector).tabularFormset(selector, inlineOptions.options);
 // change to
 selector = inlineOptions.name + "-group .tabular.inline-related
 tbody:first > tr[id^=" + inlineOptions.name.substring(1) + "-].form-row ";
 $(this).children().tabularFormset(selector, inlineOptions.options);
 }}}

 I only add "id" from every inline in jquery selector.

 This is not impossible situation, i include additional inline for my needs
 directly in html, and founded this 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/052.2605490b16338bc51599830b083ea47f%40djangoproject.com.

Re: [Django] #28135: simplify_regex() doesn't handle non-capturing groups

[Django]

#28135: simplify_regex() doesn't handle non-capturing groups
-+-
 Reporter:  German M. Bravo  |Owner:  Ayush
 Type:   |  Joshi
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admindocs|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Ayush Joshi):

 I've created a patch for this issue I'm about to make a PR :).

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

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

Re: [Django] #28135: simplify_regex() doesn't handle non-capturing groups

[Django]

#28135: simplify_regex() doesn't handle non-capturing groups
-+-
 Reporter:  German M. Bravo  |Owner:  Ayush
 Type:   |  Joshi
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admindocs|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Ayush Joshi):

 * owner:  Felix Zhang => Ayush Joshi


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

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

Re: [Django] #33300: Hidden fields are visible on small screens.

[Django]

#33300: Hidden fields are visible on small screens.
-+-
 Reporter:  Maxim Danilov|Owner:  Shubh
 |  Parmar
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  admin, modeladmin,   | Triage Stage:  Accepted
  css|
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-

Comment (by Shubh Parmar):

 PR [https://github.com/django/django/pull/15255]

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

[Django] #33393: Weird title level in logging how-to

[Django]

#33393: Weird title level in logging how-to
+
   Reporter:  Claude Paroz  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Documentation |Version:  4.0
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 In the logging how-to, the title of section `Using logger hierarchies and
 propagation` appears very small:

 https://docs.djangoproject.com/en/4.0/howto/logging/#using-logger-
 hierarchies-and-propagation

 Either it is defined in the wrong level (under or below `Use logger
 namespacing`?), or the docs style sheet has an issue with titles of that
 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/050.729ea53f90171180a57f33725ef2874c%40djangoproject.com.