Dynamically limiting queryset of related field

Question

Using Django REST Framework, I want to limit which values can be used in a related field in a creation.

For example consider this example (based on the filtering example on https://web.archive.org/web/20140515203013/http://www.django-rest-framework.org/api-guide/filtering.html, but changed to ListCreateAPIView):

class PurchaseList(generics.ListCreateAPIView)
    model = Purchase
    serializer_class = PurchaseSerializer

    def get_queryset(self):
        user = self.request.user
        return Purchase.objects.filter(purchaser=user)

In this example, how do I ensure that on creation the purchaser may only be equal to self.request.user, and that this is the only value populated in the dropdown in the form in the browsable API renderer?

Allanrbo · Accepted Answer · 2013-03-12T18:24:58.140

45

I ended up doing something similar to what Khamaileon suggested here. Basically I modified my serializer to peek into the request, which kind of smells wrong, but it gets the job done... Here's how it looks (examplified with the purchase-example):

class PurchaseSerializer(serializers.HyperlinkedModelSerializer):
    def get_fields(self, *args, **kwargs):
        fields = super(PurchaseSerializer, self).get_fields(*args, **kwargs)
        fields['purchaser'].queryset = permitted_objects(self.context['view'].request.user, fields['purchaser'].queryset)
        return fields

    class Meta:
        model = Purchase

permitted_objects is a function which takes a user and a query, and returns a filtered query which only contains objects that the user has permission to link to. This seems to work both for validation and for the browsable API dropdown fields.

edited Mar 12 '13 at 18:24

answered Mar 12 '13 at 18:03

Allanrbo

2,278
1
23
27

In my case I used another ModelSerializer as a field, so I needed to make a so bigger roundup... – alanjds Jun 28 '13 at 18:43
5

With DRF 3.0, this doesn't work anymore, as their querysets are nested deeper and deeper into `field.child_relation`. – TankorSmash May 27 '15 at 18:07
3

Is there any way to accomplish the same on DRF 3.1? – Gokhan Sari Jun 30 '15 at 15:19
yes, it's possible to do this, I'm going to add solution below – Aug 04 '15 at 18:15
I will post the way you can do it below. – Sep 14 '15 at 19:21

score 18 · Answer 2 · edited Dec 29 '15 at 18:25

Here's how I do it:

class PurchaseList(viewsets.ModelViewSet):
    ...
    def get_serializer(self, *args, **kwargs):
        serializer_class = self.get_serializer_class()
        context = self.get_serializer_context()
        return serializer_class(*args, request_user=self.request.user, context=context, **kwargs)

class PurchaseSerializer(serializers.ModelSerializer):
    ...
    def __init__(self, *args, request_user=None, **kwargs):
        super(PurchaseSerializer, self).__init__(*args, **kwargs)
        self.fields['user'].queryset = User._default_manager.filter(pk=request_user.pk)

score 16 · Answer 3 · answered Jul 24 '19 at 13:28

The example link does not seem to be available anymore, but by reading other comments, I assume that you are trying to filter the user relationship to purchases.

If i am correct, then i can say that there is now an official way to do this. Tested with django rest framework 3.10.1.

class UserPKField(serializers.PrimaryKeyRelatedField):
    def get_queryset(self):
        user = self.context['request'].user
        queryset = User.objects.filter(...)
        return queryset

class PurchaseSeriaizer(serializers.ModelSerializer):
    users = UserPKField(many=True)

    class Meta:
        model = Purchase
        fields = ('id', 'users')

This works as well with the browsable API.

Sources:

https://github.com/encode/django-rest-framework/issues/1985#issuecomment-328366412

https://medium.com/django-rest-framework/limit-related-data-choices-with-django-rest-framework-c54e96f5815e

score 10 · Answer 4 · answered Nov 03 '15 at 02:27

I disliked the style of having to override the init method for every place where I need to have access to user data or the instance at runtime to limit the queryset. So I opted for this solution.

Here is the code inline.

from rest_framework import serializers


class LimitQuerySetSerializerFieldMixin:
    """
    Serializer mixin with a special `get_queryset()` method that lets you pass
    a callable for the queryset kwarg. This enables you to limit the queryset
    based on data or context available on the serializer at runtime.
    """

    def get_queryset(self):
        """
        Return the queryset for a related field. If the queryset is a callable,
        it will be called with one argument which is the field instance, and
        should return a queryset or model manager.
        """
        # noinspection PyUnresolvedReferences
        queryset = self.queryset
        if hasattr(queryset, '__call__'):
            queryset = queryset(self)
        if isinstance(queryset, (QuerySet, Manager)):
            # Ensure queryset is re-evaluated whenever used.
            # Note that actually a `Manager` class may also be used as the
            # queryset argument. This occurs on ModelSerializer fields,
            # as it allows us to generate a more expressive 'repr' output
            # for the field.
            # Eg: 'MyRelationship(queryset=ExampleModel.objects.all())'
            queryset = queryset.all()
        return queryset


class DynamicQuersetPrimaryKeyRelatedField(LimitQuerySetSerializerFieldMixin, serializers.PrimaryKeyRelatedField):
    """Evaluates callable queryset at runtime."""
    pass


class MyModelSerializer(serializers.ModelSerializer):
    """
    MyModel serializer with a primary key related field to 'MyRelatedModel'.
    """
    def get_my_limited_queryset(self):
        root = self.root
        if root.instance is None:
            return MyRelatedModel.objects.none()
        return root.instance.related_set.all()

    my_related_model = DynamicQuersetPrimaryKeyRelatedField(queryset=get_my_limited_queryset)

    class Meta:
        model = MyModel

The only drawback with this is that you would need to explicitly set the related serializer field instead of using the automatic field discovery provided by ModelSerializer. i would however expect something like this to be in rest_framework by default.

score 6 · Answer 5 · edited Jun 13 '18 at 23:32

In django rest framework 3.0 the get_fields method was removed. But in a similar way you can do this in the init function of the serializer:

class PurchaseSerializer(serializers.HyperlinkedModelSerializer):
    class Meta:
        model = Purchase

    def __init__(self, *args, **kwargs):
        super(PurchaseSerializer, self).__init__(*args, **kwargs)
        if 'request' in self.context:
            self.fields['purchaser'].queryset = permitted_objects(self.context['view'].request.user, fields['purchaser'].queryset)

I added the if check since if you use PurchaseSerializer as field in another serializer on get methods, the request will not be passed to the context.

score 3 · Answer 6 · answered Mar 11 '13 at 20:42

First to make sure you only allow "self.request.user" when you have an incoming http POST/PUT (this assumes the property on your serializer and model is named "user" literally)

def validate_user(self, attrs, source):
    posted_user = attrs.get(source, None)
    if posted_user:
        raise serializers.ValidationError("invalid post data")
    else:
        user = self.context['request']._request.user
        if not user:
            raise serializers.ValidationError("invalid post data")
        attrs[source] = user
    return attrs

By adding the above to your model serializer you ensure that ONLY the request.user is inserted into your database.

2) -about your filter above (filter purchaser=user) I would actually recommend using a custom global filter (to ensure this is filtered globally). I do something for a software as a service app of my own and it helps to ensure each http request is filtered down (including an http 404 when someone tries to lookup a "object" they don't have access to see in the first place)

I recently patched this in the master branch so both list and singular views will filter this

https://github.com/tomchristie/django-rest-framework/commit/1a8f07def8094a1e34a656d83fc7bdba0efff184

3) - about the api renderer - are you having your customers use this directly? if not I would say avoid it. If you need this it might be possible to add a custom serlializer that would help to limit the input on the front-end

Thanks for your suggestions! I was actually hoping I could let my customers use the browsable API directly, so they could explore and experiment. One question: where/how would you implement the custom global filter you mentioned? — Allanrbo, Mar 12 '13 at 17:54
Sure, first pip install django-filter. Next subclass DjangoFilterBackend and override the filter_queryset method (to chain your customer.filter). Last add the settings to tell DRF that you want this filter applied with each request http://django-rest-framework.org/api-guide/filtering.html#generic-filtering — Toran Billups, Mar 13 '13 at 00:42

Andrew P · Answer 7 · 2015-09-14T19:53:04.077

Upon request @ gabn88, as you may know by now, with DRF 3.0 and above, there is no easy solution. Even IF you do manage to figure out a solution, it won't be pretty and will most likely fail on subsequent versions of DRF as it will override a bunch of DRF source which will have changed by then.

I forget the exact implementation I used, but the idea is to create 2 fields on the serializer, one your normal serializer field (lets say PrimaryKeyRelatedField etc...), and another field a serializer method field, which the results will be swapped under certain cases (such as based on the request, the request user, or whatever). This would be done on the serializers constructor (ie: init)

Your serializer method field will return a custom query that you want. You will pop and/or swap these fields results, so that the results of your serializer method field will be assigned to the normal/default serializer field (PrimaryKeyRelatedField etc...) accordingly. That way you always deal with that one key (your default field) while the other key remains transparent within your application.

Along with this info, all you really need is to modify this: http://www.django-rest-framework.org/api-guide/serializers/#dynamically-modifying-fields

score 0 · Answer 8 · answered May 24 '15 at 00:39

I wrote a custom CustomQueryHyperlinkedRelatedField class to generalize this behavior:

class CustomQueryHyperlinkedRelatedField(serializers.HyperlinkedRelatedField):
    def __init__(self, view_name=None, **kwargs):
        self.custom_query = kwargs.pop('custom_query', None)
        super(CustomQueryHyperlinkedRelatedField, self).__init__(view_name, **kwargs)

    def get_queryset(self):
        if self.custom_query and callable(self.custom_query):
            qry = self.custom_query()(self)
        else:
            qry = super(CustomQueryHyperlinkedRelatedField, self).get_queryset()

        return qry

    @property
    def choices(self):
        qry = self.get_queryset()
        return OrderedDict([
            (
                six.text_type(self.to_representation(item)),
                six.text_type(item)
            )
            for item in qry
        ])

Usage:

class MySerializer(serializers.HyperlinkedModelSerializer):
    ....
    somefield = CustomQueryHyperlinkedRelatedField(view_name='someview-detail',
                        queryset=SomeModel.objects.none(),
                        custom_query=lambda: MySerializer.some_custom_query)

    @staticmethod
    def some_custom_query(field):
        return SomeModel.objects.filter(somefield=field.context['request'].user.email)
    ...

score 0 · Answer 9 · answered Jun 25 '15 at 15:37

I did the following:

class MyModelSerializer(serializers.ModelSerializer):
    myForeignKeyFieldName = MyForeignModel.objects.all()

    def get_fields(self, *args, **kwargs):
        fields = super(MyModelSerializer, self).get_fields()
        qs = MyModel.objects.filter(room=self.instance.id)
        fields['myForeignKeyFieldName'].queryset = qs
        return fields

score 0 · Answer 10 · answered Sep 29 '21 at 12:30

I looked for a solution where I can set the queryset upon creation of the field and don't have to add a separate field class. This is what I came up with:

class PurchaseSerializer(serializers.HyperlinkedModelSerializer):
    class Meta:
        model = Purchase
        fields = ["purchaser"]

    def get_purchaser_queryset(self):
        user = self.context["request"].user
        return Purchase.objects.filter(purchaser=user)

    def get_extra_kwargs(self):
        kwargs = super().get_extra_kwargs()
        kwargs["purchaser"] = {"queryset": self.get_purchaser_queryset()}
        return kwargs

The main issue for tracking suggestions regarding this seems to be drf#1985.

score 0 · Answer 11 · answered May 11 '22 at 05:38

Here's a re-usable generic serializer field that can be used instead of defining a custom field for every use case.

class DynamicPrimaryKeyRelatedField(serializers.PrimaryKeyRelatedField):
    """A PrimaryKeyRelatedField with ability to set queryset at runtime.

    Pass a function in the `queryset_fn` kwarg. It will be passed the serializer `context`.
    The function should return a queryset.
    """

    def __init__(self, queryset_fn=None, **kwargs):
        assert queryset_fn is not None, "The `queryset_fn` argument is required."
        self.queryset_fn = queryset_fn
        super().__init__(**kwargs)

    def get_queryset(self):
        return self.queryset_fn(context=self.context)

Usage:

class MySerializer(serializers.ModelSerializer):
    
    my_models = DynamicPrimaryKeyRelatedField(
        queryset_fn=lambda context: MyModel.objects.visible_to_user(context["request"].user)
    )

    # ...

Same works for serializers.SlugRelatedField.

Dynamically limiting queryset of related field

11 Answers11

Linked