limit_choices_to=function() not work in python-3.6+django-1.11.2
86 views
Skip to first unread message
Drunkard Zhang
Jun 28, 2017, 7:10:35 AM6/28/17
to Django users
Hi, fellows:
I was running python-3.4+django-1.9.13 previous, and upgrading to python-3.6+django-1.11.2, while testing, I found that my limit_choices_to function not working now, here's detail.
I'm using a middleware to get current user who is accessing my site, and use it in limit_choices_to function, to provide different filter based on current user. This works great with python-3.4 + django-1.9.13; and using django-crispy-forms to render user forms.
After upgraded to python-3.6+django-1.11, limit_choices_to function didn't called when I opened a USER EDIT FORM (by adding print() to the function), but it still works with django admin.
So the question is:
1. The difference of init procedures between django 1.9.13 and 1.11.2? Because 1.9.13 won't exec limit_choices_to function on init, while 1.11.2 does.
2. Where should I fix the problem? django init settings, my form, or even django-crispy-forms?
I was running python-3.4+django-1.9.13 previous, and upgrading to python-3.6+django-1.11.2, while testing, I found that my limit_choices_to function not working now, here's detail.
I'm using a middleware to get current user who is accessing my site, and use it in limit_choices_to function, to provide different filter based on current user. This works great with python-3.4 + django-1.9.13; and using django-crispy-forms to render user forms.
After upgraded to python-3.6+django-1.11, limit_choices_to function didn't called when I opened a USER EDIT FORM (by adding print() to the function), but it still works with django admin.
So the question is:
1. The difference of init procedures between django 1.9.13 and 1.11.2? Because 1.9.13 won't exec limit_choices_to function on init, while 1.11.2 does.
2. Where should I fix the problem? django init settings, my form, or even django-crispy-forms?
Tim Graham
Jun 28, 2017, 7:56:36 AM6/28/17
to Django users
To get some insight, I'd try bisecting to find the Django commit where the behavior changed:
https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/#bisecting-a-regression
https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/#bisecting-a-regression
Drunkard Zhang
Jun 28, 2017, 10:11:35 AM6/28/17
to Django users
On Wednesday, June 28, 2017 at 7:56:36 PM UTC+8, Tim Graham wrote:
To get some insight, I'd try bisecting to find the Django commit where the behavior changed:
https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/#bisecting-a-regression
After a whole day digging that, I found the commit changed the behaviour: 6abd6c598ea23e0a962c87b0075aa2f79f9ead36, and the ticket: https://code.djangoproject.com/ticket/27563
I'm feeding back to upstream.
Drunkard Zhang
Jun 28, 2017, 10:42:50 AM6/28/17
to Django users
On Wednesday, June 28, 2017 at 10:11:35 PM UTC+8, Drunkard Zhang wrote:
On Wednesday, June 28, 2017 at 7:56:36 PM UTC+8, Tim Graham wrote:To get some insight, I'd try bisecting to find the Django commit where the behavior changed:
https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/#bisecting-a-regression
After a whole day digging that, I found the commit changed the behaviour: 6abd6c598ea23e0a962c87b0075aa2f79f9ead36, and the ticket: https://code.djangoproject.com/ticket/27563
I'm feeding back to upstream.
Should I open a new regression report for this?
Tim Graham
Jun 28, 2017, 5:03:54 PM6/28/17
to Django users
A new ticket is appropriate since the changes for the original ticket are already released. Please include more explicit steps about how to reproduce the issue -- it's difficult for me to tell exactly what the issue is from the details you provided so far.
Tim Graham
Jun 28, 2017, 10:00:14 PM6/28/17
to Django users
The new ticket is https://code.djangoproject.com/ticket/28345.
Reply all
Reply to author
Forward
0 new messages