Closed sevenseacat closed 1 month ago
Yep, it does :)
Actually now I'm not sure...that probably does need to change, but it wouldn't solve the issue I don't think.
oh, duh. Its &&
not ||
is all :)
I don't think is it. Should we have tests for this stuff?
json_api do
type "artist"
includes [:albums]
derive_filter? false
end
After updating, I still have the filter
option in swagger UI, it's just not pre-populated with content anymore. Redoc still shows the full set of options.
Putting it at the route level still works.
We should have tests, yes. And there are tests, but it's not 100% coverage, as you're discovering. but for example, in /open_api_test.exs
%OpenApiSpex.Operation{} = operation = api_spec.paths["/authors/no_filter"].get
refute Enum.any?(operation.parameters, &(&1.name == :filter))
The way that derive_filter?
is meant to work (at least the way I intended it to work) is that derive_filter?
on the resource would disable all filter derivation everywhere. So route.derive_filter?
is only useful for turning it off. So it should be derive_filter?(resource) && route.derive_filter?
. There may be another place that I'm not checking both places.
Hm... as far as I can tell, we are always checking in both places...
okay, so has_index_route?
didn't need to be && derive_filter?(resource)
because it was already inside a function that was checking that.
Got it reproduced in a test. We were only testing the route specific option.
alas, twas a typo.
This works as expected now, thank you :D
The docs say this should be supported at the resource level, but after adding it to my
json_api
block:I still have
filter
appearing in Swagger UI:Adding it to an individual route (ie.
index :search
) does work as expected.In
open_api.ex
there is one reference toroute.derive_filter?
that looks a bit sketchy to me:Does this need to be
route.derive_filter? || AshJsonApi.Resource.Info.derive_filter?(resource)
?