1.33.0 — Date-range filters stay on the listed model; saves keep the caller's graph

2026-10-07

A list request's dr_field is now limited to a date column of the listed model itself. A related path such as user__last_login, a JSON path, a sensitive field or a non-date column is refused with a 400 instead of being applied, which closes a count oracle on related rows. This is a minor release because a dr_field value that used to be accepted now 400s. Also, a member whose save attaches a group gets the response graph they asked for instead of the slim basic graph.

Breaking

• dr_field on a list request must name a concrete, non-relation, non-sensitive DateField or DateTimeField of the listed model. A related path (user__last_login), a JSON path, a sensitive field or a non-date column is refused with a 400 when a dr_start or dr_end is sent. A dr_field sent without a range is still ignored, as before.

Security

• Date-range filtering could be pointed through a foreign key at any reachable row's date column, and count, _mode=count and _stats all applied that filter. A tenant member could binary-search another user's last_login through dr_field=user_ref__last_login&dr_start=…, including users reachable through a membership walk into another tenant. The guard above closes it for every model; a model may narrow further by overriding on_rest_list_date_range_filter.

Fixed

• A plain member saving a row with a group key got the saved row back in the model's own basic graph when it defined one, because the group VIEW check during the foreign-key attach set the request graph to basic and the response was serialized with it. The caller's graph is restored after each attached field; the graph is still permission-checked on the way out.

Upgrade notes

• Audit clients that pass dr_field with a __ in it; they will receive a 400 after upgrading. Use a date column of the model being listed.