Here is one place that I can’t use the dynamic relation filter:
This is from a Button whose Action is “Link entities (Ask User)”, for a self-related M2M collection.
The filter does remember its setting, which is great
Here is one place that I can’t use the dynamic relation filter:
This is from a Button whose Action is “Link entities (Ask User)”, for a self-related M2M collection.
The filter does remember its setting, which is great
This is not a bug.
When you press a button, the execution of actions is actually done on a batch of entities. If you press a button in entity view, the batch is an array of only one item, but in other views (e.g. table view) it is possible to execute a button on multiple entities at once (by selecting multiple rows).
This means that it is not possible to use dynamic relation filters. In @Matt_Blais 's example above, there may be more than one value for ‘This Task → Project’, and accordingly the filter is not applied.
It is related to what is discussed here.
Actually in my case above, there can be only one Project linked to the Task – that is a one:many relation.
The M2M collection is Task:Task, and I want the filter to find all Tasks that are also linked to the same Project as the subject entity Task.
Is that not a reasonable use case?
It’s not about the number of Projects that can be linked to a Task, it’s about the number of Tasks that the button is running on.
If you select multiple rows in a Task table and choose this button action, there is not necessarily a unique Project for all of them.
I understand that there are M:M cases where the filter would not make sense – and it’s behaving as expected for those cases.
However there are ALSO cases where the filter WOULD make sense and would be very useful (i.e. in my situation when invoked on a single Task, where there is no possibility of M:M), but the filter apparently was not designed to support these cases.
So, call it a feature request instead of a bug.
Understood. The challenge is that buttons operate on an array of entities, even if that is often an array of 1.
There would need to be some thought put into how to distinguish this case, and it’s not trivial. At the moment, buttons are not in focus for any development work, so I don’t imagine much will happen here any time soon.
Or perhaps the underlying Relation Filters could be “upgraded” to handle this case, and not anything Button-specific
I don’t understand how you think that could work, can you explain what you mean.
A place in which this could work is in internal forms, as that will always be one entity at a time. But the Relation Filters still also do not work there. I suspect it’s a similar reason they also don’t work in @Yuri_BC 's screenshot. They currently only work when its already a created entity, not a form/button input. That’s how I could see them upgraded, but maybe Matt has a different idea.
I’m just speculating about different ways such a feature might be added, knowing nothing about how the existing relations filter is actually implemented – i.e. I don’t know what I’m talking about.
Putting some extra attention to this issue, since its an incongruency with how dynamic filtering currently is possible in entity fields.
See this use case where a new rating is added using a button, where the Rating Type should determine what options are available for the user.
E.g. Interest, Actionability, Relevance, etc.
Currently does not work in buttons.
I also ran into this issue.
A client project can only have 1 product. A template for that client can also only have 1 product. It’s odd that I can’t only show the templates that are applicable for the product of the entity.
What would be ideal for our use cases:
I agree with this here as we are running into the same issue.