Introduction

A ModelForm that shows every related row is usually too broad for a real application. Permissions, tenancy, ownership, and record status often determine which ForeignKey values a user should be allowed to select. The usual solution is to filter the field queryset inside the form and pass the right context from the view.

Filter the Queryset in the Form Constructor

The most maintainable place to restrict ForeignKey choices is the form class itself. That keeps the rule close to the field and avoids duplicating logic across views.

1from django import forms
2from .models import Customer, Order
3
4
5class OrderForm(forms.ModelForm):
6    class Meta:
7        model = Order
8        fields = ["customer", "total"]
9
10    def __init__(self, *args, user=None, **kwargs):
11        super().__init__(*args, **kwargs)
12        queryset = Customer.objects.none()
13        if user is not None:
14            queryset = Customer.objects.filter(
15                account=user.account,
16                is_active=True,
17            )
18        self.fields["customer"].queryset = queryset

Defaulting to none() is intentional. If the caller forgets to pass the expected context, the form fails safe instead of exposing every related object in the database.

Pass Context from the View

The form can only filter correctly if the view supplies the necessary context. In a function-based view, that often means passing the authenticated user.

1from django.shortcuts import redirect, render
2from .forms import OrderForm
3
4
5def create_order(request):
6    if request.method == "POST":
7        form = OrderForm(request.POST, user=request.user)
8        if form.is_valid():
9            form.save()
10            return redirect("orders:list")
11    else:
12        form = OrderForm(user=request.user)
13
14    return render(request, "orders/create.html", {"form": form})

For class-based views, use get_form_kwargs so every form instance receives the same context.

1from django.views.generic import CreateView
2from .forms import OrderForm
3from .models import Order
4
5
6class OrderCreateView(CreateView):
7    model = Order
8    form_class = OrderForm
9    template_name = "orders/create.html"
10
11    def get_form_kwargs(self):
12        kwargs = super().get_form_kwargs()
13        kwargs["user"] = self.request.user
14        return kwargs

Filter by Parent Object Instead of User

Sometimes the allowed choices depend on a parent object rather than on the current user directly. A common example is limiting assignees to the members of the current project.

1class TaskForm(forms.ModelForm):
2    class Meta:
3        model = Task
4        fields = ["assignee", "title"]
5
6    def __init__(self, *args, project=None, **kwargs):
7        super().__init__(*args, **kwargs)
8        members = project.members.filter(is_active=True) if project else User.objects.none()
9        self.fields["assignee"].queryset = members

This works well when the route or enclosing object already defines the business scope.

Keep Server-Side Validation

Restricting the HTML dropdown is helpful, but it is not enough. A user can still submit an ID manually. Django validates ModelChoiceField selections against the current queryset, but extra business rules often belong in a custom cleaner.

1from django import forms
2
3
4class OrderForm(forms.ModelForm):
5    # __init__ omitted for brevity
6
7    def clean_customer(self):
8        customer = self.cleaned_data["customer"]
9        if not customer.is_active:
10            raise forms.ValidationError("Customer is inactive.")
11        return customer

That protects you from edge cases such as a record being deactivated after the form was rendered but before it was submitted.

Django Admin Uses a Different Hook

If you need similar filtering inside the admin interface, form logic alone may not be enough. Django admin commonly uses formfield_for_foreignkey.

1from django.contrib import admin
2from .models import Customer, Order
3
4
5@admin.register(Order)
6class OrderAdmin(admin.ModelAdmin):
7    def formfield_for_foreignkey(self, db_field, request, **kwargs):
8        if db_field.name == "customer":
9            kwargs["queryset"] = Customer.objects.filter(is_active=True)
10        return super().formfield_for_foreignkey(db_field, request, **kwargs)

That keeps staff-facing forms aligned with your business rules.

Performance and Tests

Filtering a queryset is usually cheap, but large related tables can make forms slow. Add indexes for fields used in the filter, avoid unnecessary joins, and use an autocomplete widget if the choice list is very large.

It is also worth testing the filtered queryset directly.

1def test_customer_choices_are_limited_to_active_account_customers(user_factory, customer_factory):
2    user = user_factory()
3    allowed = customer_factory(account=user.account, is_active=True)
4    customer_factory(account=user.account, is_active=False)
5    customer_factory(is_active=True)
6
7    form = OrderForm(user=user)
8    assert list(form.fields["customer"].queryset) == [allowed]

Tests like this catch permission regressions early, which matters more than template appearance.

Common Pitfalls

The most common pitfall is filtering in the view instead of in the form. The first time another view reuses the same form, the restriction disappears.

Another common mistake is forgetting to pass user, project, or another required object into the constructor. That can lead to an empty list or an unsafe fallback.

Finally, do not trust client-side filtering as a security control. The server-side queryset and validation logic are the real enforcement layer.

Summary

• Filter ForeignKey choices by setting the field queryset inside ModelForm.__init__.
• Pass the required context from the view through explicit form kwargs.
• Default to an empty queryset when context is missing so the form fails safely.
• Keep server-side validation for forged submissions and race-condition edge cases.
• Use admin-specific hooks when the same rule must apply in Django admin.