Changes between Initial Version and Version 1 of Ticket #28345
- Timestamp:
- Jun 28, 2017, 8:57:59 PM (7 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #28345
- Property Cc added
- Property Severity Normal → Release blocker
- Property Triage Stage Unreviewed → Accepted
- Property Summary #27563 caused regression to ModelForm → limit_choices_to callable is no longer applied during ModelForm instantiation which blocks some use cases
-
Ticket #28345 – Description
initial v1 1 This change breaks inheriting from django.forms.models.ModelForm directly.1 I'm upgrading to Django 1.11.2 and found that `limit_choices_to` is applied to forms too early. It's caused by commit 6abd6c598ea23e0a962c87b0075aa2f79f9ead36 (ticket #27563). 2 2 3 I'm u pgrading to python3.6 + django-1.11.2, and gets wrong, the choice field is always empty, caused by this commit 6abd6c598ea23e0a962c87b0075aa2f79f9ead36, and it's ticket is https://code.djangoproject.com/ticket/27563 . I'm using dynamic limit_choices_to function to get user specific filter expr.3 I'm using dynamic limit_choices_to function to get user specific filter expr. It just called once during develop server init, and won't be call while open a USER EDIT FORM, which is inherited from ModelForm, but it work in django admin edit page, by reading the code, django admin build form using modelform_factory(), with this commit reverted, my customized form works just fine. So, I think it's a regression. 4 4 5 It just called once during develop server init, and won't be call while open a USER EDIT FORM, which is inherited from ModelForm, but it work in django admin edit page, by reading the code, django admin build form using modelform_factory(), with this commit reverted, my customized form works just fine. So, I think it's a regression. 6 7 Or, the usage of ModelForm changed? but newest doc not mentioned. 8 9 Below is key part of test project saying the problem: 5 Below is key part of test project showing the problem: 10 6 11 7 proj/middleware.py