[patch] allow callable values for limit_choices_to

[michael@…]

Allow limit_choices_to to test for and invoke callable value arguments. This would allow filtering on dynamically determined values. It enhances the possibilities for customising the admin interface. This may be related to Ticket 2193 (sounds similar at any rate).

For example:

def assigned_tasks():
   return get_assigned_tasks_id_list(blah, blah)

class TimeRecord(models.Model):
   task = models.ForeignKey(Task, limit_choices_to = {'id__in': assigned_tasks})

[michael@…]

test callable(value) in db/models/query.py

[Adrian Holovaty]

I agree with the concept, but the patch is incorrect -- the check for callable() should be made only on the limit_choices_to values, not in the code that parses *every* query. Could you have another look?

[Adrian Holovaty]

Removing [patch] from the subject, because the patch is invalid.

[michael@…]

I took another look - I only have limited familiarity with the code.

The value of limit_choices_to is passed to complex_filter() in three places:

django/contrib/admin/views/main.py
django/db/models/manipulators.py
django/db/models/fields/__init__.py

I believe that calls to complex_filter() are the only places limit_choices_to is actually used.

The limit_choices_to is always obtained via referencing some fragment such as .rel.limit_choices_to
The "rel" class needs a method (hopefully in some base class) that evaluates its' limit_choices_to and returns a new hashmap:

    def get_limit_choices_to(self):
        limiters = {}
        if self.limit_choices_to:
            for id in self.limit_choices_to:
                value = self.limit_choices_to[id]
                if callable(value):
                    value = value()
                limiters[id] = value
        return limiters

The existing direct references to ref.limit_choices_to need to change to ref.get_limit_choices_to()

Does this sound like I'm on the right track? I'm proceeding on these lines for now.

[michael@…]

Patch to allow evaluation of callables in limit_choices_to

[michael@…]

I attached a new patch that attempts to implement callables in limit_choices_to without involving query.py. I've put [patch] back in the header. The new patch is larger - I'm open to suggestions on how it might be more simply achieved.

[Gary Wilson <gary.wilson@…>]

I like the idea (touched on in #1891) of getting rid of limit_choices_to in favor of a choices that accepts QuerySets or callables.

[webograph <webograph@…>]

i think that callables should be passed a reference to self, at least if they accept it -- think of the following model:

class Mother(models.Model):
    firstborn = models.ForeignKey('Child', limit_choices_to={'mother':lambda me: me})
    
class Child(models.Model):
    mother = models.ForeignKey('Mother', related_name='children')

[jkocherhans]

We discussed this in Chicago and I think the plan is to allow some special methods to generate the choices.

class SomeOtherModel(models.Model):
    name = models.CharField(max_length=255)

class MyModel(models.Model):
    test = models.ForeignKey(SomeOtherModel):

    def choices_for_test(self):
        """Hook for providing custom choices. Returns a queryset or an iterable of choices tuples."""
        return SomeOtherModel.objects.all()

[Dmitri Fedortchenko <zeraien@…>]

Is anyone still working on this?

I've been seeking this functionality so I wrote a patch that actually implements jkocherhanss way of dealing with this.

By defining a function in your model called choices_forFIELDNAME you can limit the choices using data from the current row...

The patch also allows for using QuerySets for the choices attribute for any field...

I am still working on getting it to work with edit_inline, but it works perfectly with normal models.

[Dmitri Fedortchenko <zeraien@…>]

This patch is still a bit unpredictable with edit_inline objects, but works with normal relationships.

[Dmitri Fedortchenko <zeraien@…>]

Accidentally included some debug print statements in the previous patch...whoops

[Dmitri Fedortchenko <zeraien@…>]

Patch needs work since it does not work with edit inlines.

[David Grant <davidgrant@…>]

patch for newforms-admin branch. Just one line is different. Still doesn't work with inlines

[David Grant <davidgrant@…>]

What's the problem with inlines? I've been trying to figure this out all day and I can't seem to figure out what's going on. It seem to be calling the choices_for* on out-of-date instances. The only thing I can think of is that the code in models/base.py isn't being called again, so there is an old choices_for* method attached to the field.

[David Grant <davidgrant@…>]

I think the problem that appears with inlines is in attaching this method to the model's field (see content of patch). The choices_for__somefield method should not be a Field method it should be a model method (which is what it looks like anyways). This business of attaching it to the field needs to go away and the choices_for__somefield method needs to be called to filter out the choices for somefield within the context of some instance of the model (the self that is passed in).

This problem goes away if you always create an instance of the class that has the limited-choice field in it before calling the choices method. Then the choices choices_for__somefield gets reattached to the field and when you ask the field what it's choices are (via get_choices method) you get what you expect...but this is not how inlines work right now, where an instance of the inlined object is not always instantiated before looking at the field's choices, hence you will get the choices of the last-instantiated child object! But re-laod the page again and it works.

Only an instance of the model you are editing is instantiated (the non-inlined model) right away, which is why this hack works when editing the inlined model in non-in-lined mode (editing the child directly rather than through the parent).

[Alex Gaynor]

David's approach looks to be correct, however related fields don't actually have a limit_choices_to parameter, so I think we should combine this and #1891 and remove limit_choices_to entirely, and allow callables and querysets for choices, as this does.

[Matias Surdi <matiassurdi@…>]

Do yo know if this patch is going to be applied to trunk in any momment?

[Marc Fargas]

The patch is missing tests and documentation.

[hejsan]

This is quite important, without this functionality one is not able to make choices context sensitive without some major hack.

The last proposed solution, to allow for a choices_for_BLA() function is definitely the way to go, that is the only way that allows you to check your self variables and make the choices accordingly in a dynamic way.

Please someone smarter than me fix the choices_func_newforms-admin.patch patch to work for inlines also :)

[Joseph Spiros]

I'm not sure if this covers every use case, or if this is just a stupid hack that shouldn't be considered a proper solution to this problem, but what I've done is create classes that implement add_to_query (instances of which can be supplied to, I believe, any method that also accepts a Q object), and which dynamically create and add appropriate Q objects to the query upon invocation. My use case for the moment is limiting the choice of ContentTypes on the content type ForeignKey used by a GenericForeignKey. See ​ContentTypeLimiter and subclasses in my project.

[Greg Turner]

By the way, limit_choices_to can indeed be a callable (the documentation example says limit_choices_to=datetime.date.now), but doesn't include self.

[Paul Garner]

Replying to jspiros:

I'm not sure if this covers every use case, or if this is just a stupid hack that shouldn't be considered a proper solution to this problem, but what I've done is create classes that implement add_to_query (instances of which can be supplied to, I believe, any method that also accepts a Q object), and which dynamically create and add appropriate Q objects to the query upon invocation. My use case for the moment is limiting the choice of ContentTypes on the content type ForeignKey used by a GenericForeignKey. See ​ContentTypeLimiter and subclasses in my project.

That's really clever! I'm not clear how, or if it's possible, to access the current instance from within a *Limiter class though?

[stj]

patch against r15803

[stj]

Spent some time at the PyCon 2011 sprint session on this and came up with a new implementation.

The choices_for_FOO method needs to return a QuerySet though in this implementation is no check for that.
In a small test application I tested this with InlineModelAdmin and found no bugs.

[Karen Tracey]

I don't know if the previous update was a mistake or spam, but this is not fixed. Using r16279 specifying a callable for limit_choices_to raises a TypeError _filter_or_exclude() argument after ** must be a dictionary.

[Ben Davis]

Unsetting "needs test" and "needs documentation", as the latest patch seems to have both.

[myusuf3]

The newest patch no longer applies cleanly.

Setting patch needs improvement.

[Sébastien Fievet]

I'll update the patch from @stj so it apply to master.

[Sébastien Fievet]

Here's the pull-request ​https://github.com/django/django/pull/1228

[Jannis Leidel]

Repeating what I said on IRC, I think adding a field specific option into the model definition is a bad idea and doesn't have precedence in the model API. Instead I would think making it possible to pass a callable into the choices parameter of the field as mentioned by Gary a couple of years ago, makes more sense.

[Jannis Leidel]

This is related to #13181

[Christopher Adams]

I just submitted a pull request for this ticket at ​https://github.com/django/django/pull/1600.

• ForeignKey or ManyToManyField attribute limit_choices_to can now be a callable that returns either a Q object or a dict.
• The callable will be invoked at ModelForm initialization time.
• Admin form behavior modified to handle new functionality.
• Admin widget behavior modified to handle new functionality.
• Updated Django documentation field reference section.
• Added unit tests for limit_choices_to on ModelForms.
• Tweaked unit tests for Admin to use some callables for limit_choices_to.
• I included some new tests. All old test cases run successfully.

[Christopher Adams]

I submitted a new pull request that should implement this feature:
​https://github.com/django/django/pull/2233

All unit tests run on my local dev box. Added new unit test (admin_views.tests.LimitChoicesToTest) for the new feature.

Summary:

Fixed #2445 -- limit_choices_to attribute can now be a callable.

• ForeignKey or ManyToManyField attribute limit_choices_to can now be a callable that returns either a Q object or a dict.
• The callable will be invoked at ModelForm initialization time.
• Admin form behavior modified to handle new functionality.
• Admin widget behavior modified to handle new functionality.
• Updated Django documentation field reference section.
• Added unit test class using limit_choices_to on ModelForm.

[Tim Graham]

I've left some comments for improvement on the pull request.

[Christopher Adams]

Thanks Tim. I'll make the changes as requested.

[Christopher Adams]

The changes requested by @timo have been made at 5d4b7a1. I updated the pull request. See ​https://github.com/django/django/pull/2233.

commit 5d4b7a1c466174bfe05f32545652519446354c25
Author: Christopher Adams <christopher.r.adams@…>
Date: Sun Feb 9 12:02:03 2014 -0500

Made changes for #2445 requested by @timgraham on Feb 6, 2014.

• Moved ModelForm test of new limit_choices_to functionality to ./tests/model_forms/* instead of keeping them in ./tests/admin_views/*.
• Added new test in admin_views for limit_choices_to callable functionality for Django Admin.
• Updated the release notes for Django 1.7 to include a note about the new behavior for limit_choices_to.
• Added 'versionchanged' notification for limit_choices_to in the documentation for Django 1.7.
• Added explicit link to raw_id_fields in the changes to the ForeignKey.limit_choices_to documentation.
• Defined ModelForm for tests using more canonical 'fields' instead of 'exclude'.
• Refactored datetime import statement for model_forms test.
• Phrased changes to documentation in a better way where requested.
• Added missing indentation for 'note' section of proposed changes to documentation.
• Simplified inline code comments where requested.
• Removed unused imports.
• Refs #2445.

[Tim Graham <timograham@…>]

In eefc88feefec0c3685bfb102714530b751b4ae90:

Fixed #2445 -- Allowed limit_choices_to attribute to be a callable.

ForeignKey or ManyToManyField attribute limit_choices_to can now
be a callable that returns either a Q object or a dict.

Thanks michael at actrix.gen.nz for the original suggestion.

[Daniel Hahler]

Thanks! This looks very useful.

I wonder if it could be changed to pass along any request object to the callback, which would allow to look at request.user and then limit the choices to objects that the current user owns?

From what I understand the request object may not be available, e.g. when used via management commands, where None would be passed to the callback then.

[Tim Graham]

Not really, the request is generally not available in a form.

[Christopher Adams]

I know some people make the request available in thread local storage using middleware (see ​http://stackoverflow.com/questions/1057252/how-do-i-access-the-request-object-or-any-other-variable-in-a-forms-clean-met#answer-1057418). This effectively hacks Django to make its behavior similar to frameworks that make the request object globally available, such as Flask. Note however that many people believe this pattern is a bad practice.

[Baptiste Mispelon <bmispelon@…>]

In bfb11b95626f39e2f5e18d97d7761c6f93dcc1a9:

Fixed #23795 -- Fixed a regression in custom form fields

Custom form fields having a queryset attribute but no
limit_choices_to could no longer be used in ModelForms.

Refs #2445.

Thanks to artscoop for the report.

[Baptiste Mispelon <bmispelon@…>]

In 606c57a132a1e1e680853c014efc41110ee75a80:

[1.7.x] Fixed #23795 -- Fixed a regression in custom form fields

Custom form fields having a queryset attribute but no
limit_choices_to could no longer be used in ModelForms.

Refs #2445.

Thanks to artscoop for the report.

Backport of bfb11b95626f39e2f5e18d97d7761c6f93dcc1a9 from master.

Conflicts:

django/forms/fields.py