Unified data management. One system to handle all data entry, collection, and reporting, across all your unique workflows. Simplify processes. Make people happy.
Sometimes people specify conditions involving multi-select linked fields. This gets confusing.
Because generally you're matching a single value against the list. But sometimes the single value is on the left side and sometimes it's on the right.
For example, when filtering the entries included in a linked element, you might have a dynamic filter that picks up the value of another field in the form, and that value is used to filter the entries in the source form for the linked element.
Well, the dynamic filter element could allow multiple selections, and the filter element in the source form could be a single value. Or it could be vice versa, the dynamic filter element might be a single value and the filter element in the source form might have multiple values.
Generally we use LIKE in situations where there are multiple values involved, because the basic SQL you want to generate is more or less: " source value LIKE filter value "
But in cases where the question of which is single and which is multiple is reversed, then you may need to do " filter value LIKE source value "
This PR addresses that. In a rather ugly way. But the permutations of filter conditions are many and varied and short of a complete top to bottom refactor of the entire thing, this is probably as good as it gets now.
This PR also addresses handling such filters when there's an asynchronous value being inserted into the query, because of a conditional element, etc. In those cases, multiple literal values are present as a string, so we actually have to switch from LIKE to IN, just to make things extra complicated. But it works like a charm!
Sometimes people specify conditions involving multi-select linked fields. This gets confusing.
Because generally you're matching a single value against the list. But sometimes the single value is on the left side and sometimes it's on the right.
For example, when filtering the entries included in a linked element, you might have a dynamic filter that picks up the value of another field in the form, and that value is used to filter the entries in the source form for the linked element.
Well, the dynamic filter element could allow multiple selections, and the filter element in the source form could be a single value. Or it could be vice versa, the dynamic filter element might be a single value and the filter element in the source form might have multiple values.
Generally we use LIKE in situations where there are multiple values involved, because the basic SQL you want to generate is more or less: " source value LIKE filter value "
But in cases where the question of which is single and which is multiple is reversed, then you may need to do " filter value LIKE source value "
This PR addresses that. In a rather ugly way. But the permutations of filter conditions are many and varied and short of a complete top to bottom refactor of the entire thing, this is probably as good as it gets now.
This PR also addresses handling such filters when there's an asynchronous value being inserted into the query, because of a conditional element, etc. In those cases, multiple literal values are present as a string, so we actually have to switch from LIKE to IN, just to make things extra complicated. But it works like a charm!