We Keep Coding

list_filters are not working with redefined get_queryset in Admin list_view if that contains union

I needed to create Django Admin list_view page with redefined get_queryset() method that will do union by different models to the same page.
But after I updated it, list_filter stopped work.
As I find out if you use union() - Django doesn't allow to do any further filtering (only LIMIT, OFFSET, COUNT(*), ORDER BY SQL operations).
And for some reason application of these filters is implemented after call of get_queryset(). I thought that call super().get_queryset(request) in my ModelAdmin.get_queryset() will return already parsed data.
UPD: In this situation no filters working and queryset in actions always contain all model records, even if few selected just a few.
class Model1():
pass
class ModelA():
x = models.ForeignKey(Model1)
class ModelB():
x = models.ForeignKey(Model1)
class Model1Admin():
list_display = (...)
list_filters = (...) # These will not work
list_actions = (...) # These will not work
def get_queryset():
qs_a = Model1.prefetch_related('ModelA')
qs_b = Model1.prefetch_related('ModelB')
return qs_a.union(qs_b)
Questions:
Is there any simple way how to get queryset with already applied list_filters and after do my custom filtering and union?
Is this a bug in Django Framework by itself and this should be reported in their bug-tracker?

How to filter ModelAdmin autocomplete_fields results with the context of limit_choices_to

I have a situation where I wish to utilize Django's autocomplete admin widget, that respects a referencing models field limitation.
For example I have the following Collection model that has the attribute kind with specified choices.
class Collection(models.Model):
...
COLLECTION_KINDS = (
('personal', 'Personal'),
('collaborative', 'Collaborative'),
)
name = models.CharField()
kind = models.CharField(choices=COLLECTION_KINDS)
...
Another model ScheduledCollection references Collection with a ForeignKey field that implements limit_choices_to option. The purpose of this model is to associate meta data to a Collection for a specific use case.
class ScheduledCollection(models.Model):
...
collection = models.ForeignKey(Collection, limit_choices_to={'kind': 'collaborative'})
start_date = models.DateField()
end_date = models.DateField()
...
Both models are registered with a ModelAdmin. The Collection model implements search_fields.
#register(models.Collection)
class CollectionAdmin(ModelAdmin):
...
search_fields = ['name']
...
The ScheduledCollection model implements autocomplete_fields
#register(models.ScheduledCollection)
class ScheduledCollectionAdmin(ModelAdmin):
...
autocomplete_fields = ['collection']
...
This works but not entirely as expected. The autocomplete retrieves results from a view generated by the Collection model. The limit_choices_to do not filter the results and are only enforced upon save.
It has been suggested to implement get_search_results or get_queryset on the CollectionAdmin model. I was able to do this and filter the results. However, this changes Collection search results across the board. I am unaware of how to attain more context within get_search_results or get_queryset to conditionally filter the results based upon a relationship.
In my case I would like to have several choices for Collection and several meta models with different limit_choices_to options and have the autocomplete feature respect these restrictions.
I don't expect this to work automagically and maybe this should be a feature request. At this point I am at a loss how to filter the results of a autocomplete with the respect to a choice limitation (or any condition).
Without using autocomplete_fields the Django admin's default <select> widget filters the results.

Triggering off the http referer was ugly so I made a better version: subclass the AutocompleteSelect and send extra query parameters to allow get_search_results to lookup the correct limit_choices_to automagically. Simply include this mixin in your ModelAdmin (for both source and target models). As a bonus it also adds a delay to the ajax requests so you don't spam the server as you type in the filter, makes the select wider and sets the search_fields attribute (to 'translations__name' which is correct for my system, customise for yours or omit and set individually on the ModelAdmins as before):
from django.contrib.admin import widgets
from django.utils.http import urlencode
from django.contrib.admin.options import ModelAdmin
class AutocompleteSelect(widgets.AutocompleteSelect):
"""
Improved version of django's autocomplete select that sends an extra query parameter with the model and field name
it is editing, allowing the search function to apply the appropriate filter.
Also wider by default, and adds a debounce to the ajax requests
"""
def __init__(self, rel, admin_site, attrs=None, choices=(), using=None, for_field=None):
super().__init__(rel, admin_site, attrs=attrs, choices=choices, using=using)
self.for_field = for_field
def build_attrs(self, base_attrs, extra_attrs=None):
attrs = super().build_attrs(base_attrs, extra_attrs=extra_attrs)
attrs.update({
'data-ajax--delay': 250,
'style': 'width: 50em;'
})
return attrs
def get_url(self):
url = super().get_url()
url += '?' + urlencode({
'app_label': self.for_field.model._meta.app_label,
'model_name': self.for_field.model._meta.model_name,
'field_name': self.for_field.name
})
return url
class UseAutocompleteSelectMixin():
"""
To avoid ForeignKey fields to Event (such as on ReportColumn) in admin from pre-loading all events
and thus being really slow, we turn them into autocomplete fields which load the events based on search text
via an ajax call that goes through this method.
Problem is this ignores the limit_choices_to of the original field as this ajax is a general 'search events'
without knowing the context of what field it is populating. Someone else has exact same problem:
https://stackoverflow.com/questions/55344987/how-to-filter-modeladmin-autocomplete-fields-results-with-the-context-of-limit-c
So fix this by adding extra query parameters on the autocomplete request,
and use these on the target ModelAdmin to lookup the correct limit_choices_to and filter with it.
"""
# Overrides django.contrib.admin.options.ModelAdmin#formfield_for_foreignkey
# Is identical except in case db_field.name is in autocomplete fields it constructs our improved AutocompleteSelect
# instead of django's and passes it extra for_field parameter
def formfield_for_foreignkey(self, db_field, request, **kwargs):
if db_field.name in self.get_autocomplete_fields(request):
db = kwargs.get('using')
kwargs['widget'] = AutocompleteSelect(db_field.remote_field, self.admin_site, using=db, for_field=db_field)
if 'queryset' not in kwargs:
queryset = self.get_field_queryset(db, db_field, request)
if queryset is not None:
kwargs['queryset'] = queryset
return db_field.formfield(**kwargs)
return super().formfield_for_foreignkey(db_field, request, **kwargs)
# In principle we could add this override in a different mixin as adding the formfield override above is needed on
# the source ModelAdmin, and this is needed on the target ModelAdmin, but there's do damage adding everywhere so combine them.
def get_search_results(self, request, queryset, search_term):
if 'app_label' in request.GET and 'model_name' in request.GET and 'field_name' in request.GET:
from django.apps import apps
model_class = apps.get_model(request.GET['app_label'], request.GET['model_name'])
limit_choices_to = model_class._meta.get_field(request.GET['field_name']).get_limit_choices_to()
if limit_choices_to:
queryset = queryset.filter(**limit_choices_to)
return super().get_search_results(request, queryset, search_term)
search_fields = ['translations__name']

I had the exact same problem. It's a bit hacky, but here's my solution:
Override get_search_results of the ModelAdmin you are searching for and want to filter
Use the request referer header to get the magical context you need to apply the appropriate filter based on the source of the relationship
Grab the limit_choices_to from the appropriate ForeignKey's _meta
Pre-filter the queryset and then pass to super method.
So for your models:
#register(models.Collection)
class CollectionAdmin(ModelAdmin):
...
search_fields = ['name']
def get_search_results(self, request, queryset, search_term):
if '<app_name>/scheduledcollection/' in request.META.get('HTTP_REFERER', ''):
limit_choices_to = ScheduledCollection._meta.get_field('collection').get_limit_choices_to()
queryset = queryset.filter(**limit_choices_to)
return super().get_search_results(request, queryset, search_term)
A shortcoming of this approach is the only context we have is the model being edited in admin, rather than which field of the model, so if your ScheduledCollection model has 2 collection autocomplete fields (say personal_collection and collaborative_collection) with different limit_choices_to we can't infer this from the referer header and treat them differently. Also inline admins will have the referer url based on the parent thing they are an inline for, rather than reflecting their own model. But it works in the basic cases.
Hopefully a new version of Django will have a cleaner solution, such as the autocomplete select widget sending an extra query parameter with the model and field name it is editing so that get_search_results can accurately look up the required filters instead of (potentially inaccurately) inferring from the referer header.

Here is another solution to get only a subset of choices in the auto-complete field. This solution does not change the default behavior for the main model (Collection), so you can still have other views using autocomplete with the full set in your app.
Here is how it works:
Proxy model for Collection with manager
Create a proxy model to represent a subset of Collection, e.g. CollaborativeCollection to represent collections that are of kind "collaborative". You will also need a manager to restrict the initial queryset of your proxy model to the intended subset.
class CollaborativeCollectionManager(models.Manager):
def get_queryset(self):
return (
super()
.get_queryset()
.filter(kind="collaborative")
)
class CollaborativeCollection(models.Model):
class Meta:
proxy = True
objects = CollaborativeCollectionManager()
Updating foreign key to use proxy model
Next update the foreign key in ScheduledCollection to use the proxy model instead. Note that you can remove the limit_choices_to feature if you don't need it for anything else.
class ScheduledCollection(models.Model):
...
collection = models.ForeignKey(CollaborativeCollection)
start_date = models.DateField()
end_date = models.DateField()
...
Define admin model for Proxy
Finally define the admin model for the proxy.
#admin.register(CollaborativeCollection)
class CollaborativeCollectionAdmin(admin.ModelAdmin):
search_fields = ["name"]
Note that instead of the manager, you could also define a custom get_search_results() in the admin model. However, I found that the manager approach appears to be more performant. And it also is conceptually more sounds, since with that all queries to CollaborativeCollection will only return collaborative collections.

My solution is to wrap get_url method on the widget.
Create a util method as shown below.
def wrap_get_url(original_get_url, extra_url_params: QueryDict) -> Callable:
def get_url_with_extra_url_params(*args, **kwargs) -> str:
url: str = original_get_url(*args, **kwargs)
scheme, netloc, url, params, query, fragment = tuple(urlparse(url))
query = QueryDict(query_string=query, mutable=True)
query.update(extra_url_params)
url_parts = (scheme, netloc, url, params, query.urlencode(), fragment)
return urlunparse(url_parts)
return get_url_with_extra_url_params
Create a custom form for your model admin.
class ExampleModelAdminForm(forms.ModelForm):
class Meta:
model = ExampleModel
exclude: List[str] = []
def __init__(self, *args, **kwargs):
super().__init__(*args, **kwargs)
instance = getattr(self, "instance", None)
# Check for RelatedWidgetWrapper
if widget := getattr(self.fields["target_model"].widget, "widget", None):
query = QueryDict(mutable=True)
query["example_model_id"] = instance.pk
widget.get_url = wrap_get_url(
original_get_url=widget.get_url,
extra_url_params=query,
)
class ExampleModelAdmin(admin.ModelAdmin):
form = forms.ExampleModelAdminForm
autocomplete_fields = ("target_model",)
On the target model admin.
class TargetModelAdmin(admin.ModelAdmin):
search_fields = ("name", ) # Define your search fields
def get_search_results(self, request, queryset, search_term) -> tuple[QuerySet, bool]:
qs: QuerySet
duplicate: bool
qs, duplicate = super(TargetModelAdmin, self).get_search_results(request, queryset, search_term)
# Get Example model id from previous admin page in order to filter the queryset
if example_model_id := request.GET.get("example_account_id", None):
example_model: ExampleModel = ExampleModel.objects.get(
id=example_model_id
)
qs = qs.filter(field=example_model.field) # Filter your qs here
return qs, duplicate

With Django 3.2, the solution proposed by #Uberdude does not work anymore because AutocompleteSelect's constructor now takes a field rather than a relation.
Here is the updated code needed for the formfield_for_foreignkey method:
def formfield_for_foreignkey(self, db_field, request, **kwargs):
if db_field.name in self.get_autocomplete_fields(request) or\
db_field.name in self.get_autocomplete_cb_fields(request):
db = kwargs.get('using')
if db_field.name in self.get_autocomplete_cb_fields(request):
kwargs['widget'] = AutocompleteSelectCb(
db_field, self.admin_site, using=db, for_field=db_field)
else:
kwargs['widget'] = AutocompleteSelect(
db_field, self.admin_site, using=db, for_field=db_field)
if 'queryset' not in kwargs:
queryset = self.get_field_queryset(db, db_field, request)
if queryset is not None:
kwargs['queryset'] = queryset
return db_field.formfield(**kwargs)
return super().formfield_for_foreignkey(db_field, request, **kwargs)

How can I set the created instance's property in Django-Rest-Framework CreateAPIView?

How can I set the created instance's property in Django-Rest-Framework?
class ServerTaskCreateAPIView(CreateAPIView):
serializer_class = PhysicalServerTaskCreateSerializer
permission_classes = []
queryset = ServerTask.objects.all()
def perform_create(self, serializer):
# I want to set the ServerTask instance to be `Initialed`
# like instance.task_type = "Initialed"
serializer.save()
You see, I tried to rewrite the perform_create method, and find there is no instance's param. how to access the requirement?
edit
I know I can use APIView in the post method to achieve it, but that can not fit the simplicity and convenience of DRF. so I want in the DRF to do that, is it possible?

You can use this:
http://www.django-rest-framework.org/api-guide/serializers/#writing-create-methods-for-nested-representations
def create(self, validated_data):
validated_data['task_type'] = 'Initialed'
server_task = ServerTask.objects.create(**validated_data)
return server_task
Or in your case you may just want a default value on the model.

Append additional values to queryset in Django generic views before handing to template

I have the following view:
class AppointmentListView(LoginRequiredMixin, ListView):
queryset = Appointment.objects.prefetch_related('client','patients')
I need to be able to add an extra variable to each returned Appointment object based on the following:
status_choices={
'STATUS_UPCOMING':'default',
'STATUS_ARRIVED':'primary',
'STATUS_IN_CONSULT': 'success',
'STATUS_WAITING_TO_PAY':'info',
'STATUS_PAYMENT_COMPLETE':'warning',
}
The values ('default', 'primary' etc) correspond to standard css classesin Bootcamp themes that I want to use according to the type of Appointment. For example, 'default' produces a gray button, 'warning' a red button etc.
I need to map each Appointment record to a certain css button based on the record's status ('upcoming' would display the 'default' class etc).
My initial idea was to loop over the query set and build a separate array/dictionary mapping the Appointment pk to a given css class such as
1:'success', 2:'warning', and then pass that in as a context variable.
But I was wondering if I could just add the value to each Appointment object directly (perhaps saving the queryset as a list?) That would be a much cleaner solution but am not sure how that should be approached.
Any ideas much appreciated

You should overload the get_queryset method of the ListView like so
def get_queryset(self, **kwargs):
queryset = super(AppointmentListView, self).get_queryset(**kwargs)
# Add new elements here
...
return queryset

I got this working by overriding get_queryset() and giving the objects (i.e. each row in the db) an extra on-the-fly key/value:
class AppointmentListView(LoginRequiredMixin,ListView):
#friendly template context
context_object_name = 'appointments'
template_name = 'appointments/appointment_list.html'
def get_queryset(self):
qs = Appointment.objects.prefetch_related('client','patients')
for r in qs:
if r.status == r.STATUS_UPCOMING: r.css_button_class = 'default'
if r.status == r.STATUS_ARRIVED: r.css_button_class = 'warning'
if r.status == r.STATUS_IN_CONSULT: r.css_button_class = 'success'
if r.status == r.STATUS_WAITING_TO_PAY: r.css_button_class = 'danger'
if r.status == r.STATUS_PAYMENT_COMPLETE: r.css_button_class = 'info'
return list(qs)
A couple of things:
I converted the queryset qs to a list to 'freeze' it. This prevents the queryset from being re-evaluated (e.g. slice) which, in turn, would cause the on-the-fly model changes to be lost as fresh data is pulled from DB.
I needed to assign a value to template_name explicitly. When overriding get_queryset the template name is not derived automagically. As a comparison, the code below whose queryset attribute is set, generates the template name automatically:
class AppointmentListView(LoginRequiredMixin, ListView):
queryset = Appointment.objects.prefetch_related('client', 'patients')
#template name FOO_list derived automatically
#appointments/views.py
...
#can use derived name (FOO_list)
{% for appointment in appointment_list %}
...

Dynamically limiting queryset of related field

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?

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.

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)

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

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.

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.

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

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

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)
...

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

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.

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.