SendQueueFilterSet

Overview

Gives every declared filter a dotted public name, distinct from the name django-filter binds it under internally.

A filter's own name can't be dotted to begin with: it is either a Python identifier (a class attribute) or a __-joined Meta.fields entry, and neither grammar can hold a literal .. The public name is derived from it by default — every __ becomes a ., the same translation VuedaOrderingFilter applies to a path, so a filter reached through a relation (customer__formatted_name, or the customer__formatted_name__icontains django-filter itself builds for a Meta.fields lookup) is reachable under the same dotted name that path would take in ?o= or an expand — customer.formatted_name — with no configuration at all. A declared name with no __ in it (distributor, or an ordinary Meta.fields entry without a lookup suffix) has nothing to translate and keeps its own name as its public one.

The declared name stops being a recognized query parameter once renamed: nothing here keeps accepting it alongside the dotted one. Nothing needs to read it back either, because the rename reaches base_filters itself, so metadata and error messages read the same public name a request uses.

Renamed on get_filters(), the classmethod django-filter's metaclass calls to build base_filters, rather than on each instance's self.filters in __init__. drf-spectacular reads base_filters directly for the OpenAPI schema, and BaseFilterSet.__init__ sets self.filters = copy.deepcopy(self.base_filters), so renaming here is what both the schema and every instance see, in one place. Rebuilding the mapping by iterating super().get_filters() in its own order (rather than popping and re-inserting into an existing dict) also keeps each filter's declared position: building a new dict in that order changes each key's spelling and nothing else.

Meta

Source

server/vueda/vdq/filtersets.py:14

base_filters

declared_filters

Source

server/vueda/vdq/filtersets.py:13