I have noticed that the search/ filter functionality is only available when you create a table as whole block. There is a work around to still have the filter even if the page is split with two tables. However, the work around isn’t that convenient since you have to first create the table as a whole block (this is the table you would like to filter on) and later on add the second table. With this work around you are not allowed to change the initial table, since then the search/filter functionality disappears…
I have seen another request on this topic in the community some years ago, but unfortunately it’s not released yet. Would it be possible to build that we are able to select to which table the search/filter functionality needs to be applied? Would be very helpful!
Another question related to the search/filter functionality: at this moment when you’ve entered something in the search bar and afterwards select something from the table, the data entered in the search bar disappears. It would be very helpful if this data won’t be deleted (and so you don’t have to enter it over and over again), so you are able to select multiple data items based on your search criteria. Is this something you could build?
Thanks for posting this question (or these questions rather). I’ll start with your second question.
Keeping search available
There are a few situations where I think you’d want to not keep it, but those are few compared to when you do, I think. I’ll discuss this one with the development team. If we implement it, it will be for all searches on all pages, as we don’t want to add an extra decision to the wizard if we can avoid it.
Allow built-in search for other tables
This is still part of our (rather huge) overhaul of the entire front-end for the application. We decided to tackle many things together, instead of one-by-one.
This does take longer before we can release it, but over the whole it will be the better and faster solution. If we have to build each feature separately in the current structure, we still have to build it all in the new one after. And some things can only be done in that.
That is also the reason we kept the workaround (which internally is known as a defect ) you mentioned.
Alternative solution
We do have an alternative that is not considered a defect, which might be of use. It is where you make your own search fields and they work in the same way. A bit cumbersome for large numbers of search fields, yet very flexible. Here’s a video about that concept:
Hope that sheds some light on some things and helps at least a bit.
) you mentioned.