How to provide a scope (e.g. filter) for
# general
s
How to provide a scope (e.g. filter) for the records listed in the "Attach X" modal for a has_many relation? I want this modal to only allow choosing from specific records, but I did not find any field option for that. The resource's index_query also seems not to be applied (although I don't know if that would be a sufficient solution, as this specific relation needs extra scoping). NB: the fact that index_query is not applied also has the effect that there are N+1 queries when the modal gets opened. Currently the field definition looks like that:
Copy code
ruby
field :parents, as: :has_many, through: :parent_mappings, use_resource: Avo::Resources::Content, name: "Parents"
In the above example for some reason I also needed to specify
name
otherwise it would incorrectly call the field
contents
instead of
parents
. NB: I might not answer soon as I'll be offline 2 weeks
l
Hello @stale-greece-65998
attach_scope
is what you're looking for: https://docs.avohq.io/3.0/associations/has_many.html#attach_scope
s
Thanks! It works. FYI I was looking at the field options page where it doesn't appear: https://docs.avohq.io/3.0/field-options.html Perhaps the docs could be improved to reference all the options from the main options page
l
That section is for option that apply for almost all the fields
then each field have particular options
s
I understand but my mental model is "I'm searching for an option that applies to the
field
DSL, so it should be documented on the fields documentation page" Another option could be to make sure the documentation system overrides the Control-F keyboard shortcut to make sure that search is made across the entire documentation and not only the current page. Yet another alternative is to render the entire documentation as a "single page" Stripe docs combine those two approaches: infinite scroll and the control-F keyboard shortcut opens a modal which searches across everything
l
I think @lemon-wall-20836 had an attempt to make a section that renders all documentation as a "single page" and I agree that it can be helpful to search
It's complicated to add all the options to the field-options page because there are many specific options per field and it becomes easily chaotic that's why we keep general options there and for each field the specific ones
s
Perhaps just as short term solution the main fields doc page could have a list of the other option names that then links to the separate doc pages to learn more about them.
l
Thank you for the suggestions