Seems obvious but…if we have the ability to filter a list of items based on another list of items and are given the option to filter based on “is not in” then, it should also be provided the option to filter based on “is in”
Think about this. I have a list of 10 items and from that list I create a second list that has maybe 3 of the original 10 items and I want to for any reason I may choose create a third list that is the same as the second, meaning it has the same 3 of the original 10 items, it should be very simple and possible to provide the filter ‘is in’
If it was possible to create the filter ‘is not in’ to get me the 7 of the original list of 10 that ‘is not in’ the second list of 3 items, then it should be super simple to implement this ‘is in’ filter as well.
Main use case…to make more use of option sets for the purposes of sending URL parameters as a list and passing them through for search pages
I am now getting really tired of so many constraints and limitations that Bubble offers.
This one is so silly. Who in their right mind would have thought that “is not in” is sufficient and “is in” is not required?
@nicolas.bousson your workaround doesn’t work in my case. I have a list of ids that are being sent and I need to search all the items whose ids are there in the list. What you are saying works only if i have to search a thing itself in a list of things. But in my case i want to search a thing’s field in a list. In that case “convert to list” option is not coming.
Now, I came to this because when I am creating my own public API, I can’t get bubble things or option sets passed into it as parameters.
I came to create public API because our internal backend workflows can’t return anything and we have to resign to use them as public API.
Workarounds after workarounds after workarounds. There is just no end!
