Ute

Worth knowing how this landed, because it is the pattern for framework deprecations generally and knowing it saves you from being surprised again.

It was deprecated for a couple of releases before it was removed: the old behaviour kept working and emitted a deprecation warning, and then a later major release removed it entirely. So the warning was in your test output for a year before anything broke.

The lesson is to run your tests with deprecation warnings turned into errors, or at least visible, on a scheduled job rather than only on every push. Most frameworks warn generously and for a long time. The upgrades that hurt are the ones where nobody was reading the warnings.

It costs one CI job and it converts "the upgrade broke everything" into a list of small tasks you can do at your own pace.

Add a test for the rejection case, not just the display case.

The test everyone writes is "user A sees only their own options". The test that matters is "user A submits user B's option id directly and the form rejects it". Those are different code paths and only the second one is a security test.

It is three lines and it is the one that fails when somebody later moves the filtering into the view or the template for convenience.

Same thinking for the ordering: if a field is required, test that submitting it empty fails, because narrowing an option source to an empty set turns a required field into an impossible one, and that is a bug users report as "the page is broken".