-
Improvement
-
Resolution: Unresolved
-
Minor
-
None
-
4.4
-
MOODLE_404_STABLE
For me personally at least, when I use any sort of report, either report builder or otherwise, 90%+ of the time I want to do a single filter to start to reduce the number of records I'm looking at.
eg if I'm looking at the users list in MWP I want to search for 'Brendan' and I don't care if it matches the username or email or firstname I just want a smaller number of results and a few false positives are perfectly fine.
But the report builder filtering is really awkward and painful to get started, first you have have to think about which exact field you want to filter on, is it username? is it first name? Or email? Sometimes you don't actually know yet because you are exploring data.
If you look at basically any software which has functionality like RB it always has a free text search. Github does, gitlab does, Jira does, Gmail does, Google drive, etc etc everything operates first and foremost starting with a super simple and usable text search and then you can optionally refine those into only searching on specific fields.
So proposing to add a generic search field at the top of the filters. If the RB source exposes 5 fields which are of type Text then typing 'test' into the search field is under the hood linking up all 5 text filters and unioning them together. The RB source should do absolutely nothing and you get this for free. I have yet to see any report where adding this field would not have been beneficial but the only valid use case I can imagine is if the RB source didn't expose a single field of type text, like a grid of numbers.
I think just this alone would be easy to implement and be a huge UX improvement. Supporting more field types would be bonus points and also desirable, such as if you had a Select filter with 10 options it should see if any of the options match the search filter and then add them into the union. The Tags and Category filter should also be able to supported relatively easily. The Autocomplete may be slightly harder.
If there are multiple words in the free text search then they should all be treated independently as more unioned clauses.
I don't think we want to involve global search and do full text indexing or anything else like that as right now it just complicates what is essentially just UX sugar. We can already do text search we just can't do it on multiple fields at the same time and that's all we really want.