Search in relational/display fields

[superhp]

The issue
Page and Area - relational fields (separate tables), visualized through Display template.
Tag - the only field that directly belongs to table Contents.
Text - relational field/translation, displayed through Display template,

The issue is that I can only Search on Tag field that directly belongs to the Contents table (I can find "aboutus"). If I want to search in Page, Area and Text fields, I have to setup custom filters (I can't find "about us" or "footer" with standard Search). It would require 4 separate filters to search in all displayed columns which is not so convenient.

Idea
Could the "Search in items..." work in all relational/displayed columns? Either by default or even better with a possibility to select searchable fields in collection data model.

[benhaynes]

100%. I was just going through this with the team yesterday. I think we need to do one or both of the following:

• Add support for Search Services as an extension, eg: Algolia, Elastic, etc
• Create a native indexing of searchable text for all records. My (very rough) thinking here is that we have a hook/service that takes all relevant relational text and text generated by the Displays... and concat that into an indexed directus_search table for fast and comprehensive lookups.

Thoughts on the lift and implementation, @rijkvanzanten ?

[superhp]

@gmarton yes, in my example, the Tag is just a name of string type (string) field. The default search works perfectly with this particular field. The issue is with relational fields (Page, Area, Text) which are mapped fields from other relational or translation tables. For these we need to use advanced filters.

[gdcl]

Hi - chiming in, i have been struggling with a solution for simple search as well.
If the below is due to my incomplete understanding of the platform, i apologize upfront. With that out of the way:
I would actually point out that to filter for value from a single relational field is currently not quite usable. The fact that key relational fields can be visualized in the table view, but can not be filtered for value for (only for reference) makes the table view in the case of large datasets much less useful. In fact, i myself was not able to use the UI to create advanced filters for values of relational fields as @superhp suggests (i'm on directus 9.4.3 and still learning, so i might have overlooked something).

If i would be able, when i create a filter, to select a relational field, and then specify its subfields on which to filter (much like can be done in other places in the UI where you can specify filters, like in the customer permissions UI), that already would yield some key improvements.

I am not sure if i'm doing something wrong, but the ability to drill down into the subfields of a relational field are just not showing up.
To make things weirder, this DOES seem to be possible if you create a relation fields (like an M2O) to a directus system collection (like user or role).
Here is the table view

Then, here is what you can do when actually filtering

TL;DR - not sure why i'm having this and if i'm doing something wrong, but couldn't find in docs how to ensure i could filter on individual related values. If i need to file this as a separate discussion or issue, please let me know.

I certainly second the value of being able to search without specifying on which field specifically as requested by @superhp.
Any feedback would be most welcome. Thank you.

[Oreilles]

I think a great implementation would be to allow searchable fields, that could be selected with the field tree interface for each collection. It would also solve problems I have with collection that have many columns, many of them not being relevant for a global search. That would allow ignoring those fields in the search making it much faster.

The search parameter could then be converted to a filter object:

{
  _and: [
    {
      x: { _eq: "search" }
    },
    {
      y: {
        z: { _eq: "search" }
      },
    }
    ...
  ]
}

[benhaynes]

I like this approach! I also think we would benefit from indexing for faster results... which is why I keep going back to this as a good next step: #10517 (comment)

Not mutually exclusive, but we certainly need to improve the search experience, as it's counterintuitive as of now.

[benhaynes]

Also, I have pinned this within GH Discussion to give it more traction. 🙂

[u12206050]

Just my two cents.

Have a separate index per role in the system in order to accommodate the correct permissions. In addition an permission can be added to decide which collections should be indexed per role.

By default using a file based index such as flexsearch might be good enough for small-medium data sets, however larger datasets would need a dedicated service as mentioned above.

Searching an ID should return the specific item itself for quick select, as well as a short list of relationships that item is linked to. This is most beneficial with uuids or other types of globally unique IDs, compared to just using incremental ids.

[CHSchuepfer]

100% would love that!
Just stumbled upon this myself. So would be very much appreciated :)

[lessborders]

+1 - translations are kinda useless right now since you can't sort, or search by translated fields.

[FINDarkside]

Has anybody made some kind of workarounds for this? I'm thinking of just creating a hidden field in the root item and to concatenate all relational fields to a single string. Might be a bit painful to make all the hooks to update that field since the relations could change without the actual content changing though. Probably won't be good for performance but I'll have to see if the way directus searches stuff could use indexes.

[u12206050]

You could try this, until a proper search service is setup natively in directus
https://github.com/u12206050/directus-extension-global-search

[FINDarkside]

While it looks cool and useful, I don't think it's good enough UX for my usecase. I want to keep the search inside a collection instead of making a global search. Also I need to keep it simple for the end user.

[rijkvanzanten]

Heya! Thanks for opening this feature request!

This feature request has received over 15 votes from the community. This means we'll move this feature request to the Under Review state!

The Core team will schedule a meeting to review this request as soon as possible. The discussion will then be approved or denied. You may or may not be invited to join this meeting with the core team.

For more information, see our Feature Request Process.

[jvgadea]

it's totaly necesary

[Vahagn-Zaqaryan]

Hey, Directus team,

Recently, our team also came across this limitation as well, we have a team of content writers who write content in 3 languages, so most of our text fields are translations, as content grows it becomes hard and harder to search through the content.

We have some workarounds in place, but those are far from being ideal solutions.

This was a small issue at first, but now we have over 2000 content blocks, and its extremely hard even for us engineers to navigate through all that.

Thanks in advance.

[u12206050]

As a work around you can hook into the query filter and replace the search term with an explicit filter query, here is some code you can use: https://gist.github.com/u12206050/56eac1d878784a93cd81f2e34d5419a7

[Vahagn-Zaqaryan]

Thanks a lot for the suggestion, I'll explore that option as well, I also got suggested to use this extension directus-extension-global-search by u12206050 and it seems like it can solve my issue for now, thanks for the great work 💪

[FINDarkside]

Another option is to make update/create hook which fills some "search" field with all the data from relational fields you want to be searchable. That's what we've done. So we take all the titles from translations and concat them into one string. 😄 Benefit of that (and the initial suggestion) over the global search plugin is that it "just works" when you go to a collection and type stuff into the search bar. Instead of having a separate page where you must do the search.

Having filter on search might be more convenient though, didn't think of it at the time. Having only one field to search would quite certainly be faster but not sure how much.

[Vahagn-Zaqaryan]

@FINDarkside Thanks a lot for the suggestion... that actually worked quite very well, I've asked my team to create the flow today and it already made our users' lives much easier no more aikido moves to find items 😊

[rijkvanzanten]

Clever @FINDarkside! That's effectively how "search" providers (eg algolia etc) work. Afaik they'll make one big searchable hash of all the values which you then search through.

Doing nested relational search remains a tricky thing for us to support without requiring the user to first configure what fields to search through, as relational items can theoretically connect back to the whole database or have recursion etc.

That being said, one "limitation" we could bake in that might be good enough for this use case is to only search through the fields that are currently displayed on the page 🤔 (Currently search just searched through every text field in the row, regardless of if it's shown or not).