Does anyone know how to set up a controlled vocabulary in custom filter fields? Preferably typeahead vocabularies because some of these filter fields could have thousands of options.
Solved! Go to Solution.
Views
Replies
Total Likes
I hope i understood you right...
Lets say you have a tagging structure like this:
Namespace:Level1-tag/Level2-tag/Level3-tag
Your structure include the following namespaces: "vehicle makes", "models" and "trims" and each of those contain a hierarchy of tags.
You want the user to navigate it like that:
Go to the first filter, "Vehicle makes", type in something and get ONLY autofill resposes of tags that are existing as a tag under the namespace "vehicle makes"
Then the user has to go to the next filter "models" to then type in something that has to be an available tag option in models and so on...
If this is your desired outcome - please try this:
Go to your admin search rail and create create 3 tag filter predicates.
Set their root path, each to their dedicated namespace and name the filter accordingly.
"vehicle makes" to /content/cq:tags/vehicle-makes
"models" to /content/cq:tags/models and so on...
Now the user has 3 filters, which only give autofill responses based of the root path of that filter and the available tags within that structure.
If i got you wrong, please tell me where i have lost you.
Hi @dmescia2 , could you please elaborate a bit about the use case?
In our case, the only filter that gives the user the option to write something in,
is the tag-property predicate and this gets its valid options/typeahead based of the available tags.
In addition, since there are a lot of options, we had multiple tag properties with different root paths.
The tag property also gives this "open selection dialog" button to explore the tagging structure.
Most of the other search filters that we use are option predicates.
We are locking down the vocabulary for specific fields when tagging. For example, vehicle makes, models and trims. When users are searching for assets and filtering using the search rail on the left I would like to be able to use those same controlled vocabularies in those filter fields so people can't free type things.
In case you use the tags filter, i am not aware if you could make the text field so controlled that only correct letter combinations can be typed in. Since only correct tags get you a result you get a autofill based of your tagging structure.
You can create multiple tag filters, with different root paths - and put them in the order in which users receive the best search results.
You can also use the option predicate, which gives the user checkboxes you want them to have, and use tags as values for these checkboxes.
Depending on the amount of options a filter needs to have, this became the most prefered option for my users.
The behavior you are showing with the tags filter above is the behavior I'm hoping to accomplish in our DAM. But I am hoping to tie tags to custom fields. For example we'll build a hierarchy in tags for vehicle make, then apply those tags to a field for vehicle make. We were able to do something like that in the metadata tagging windows via a json file but that json list doesn't seem to be an option we can use for the custom field we create in the filters search rail. In a perfect world instead of the json file I could just have the section of my tagging structure that deals with vehicle make be the options for that field in the properties as well as the corresponding field in my filters. And if I can't use that tagging hierarchy, I'd like to at least be able to use that same json file for both.
I hope i understood you right...
Lets say you have a tagging structure like this:
Namespace:Level1-tag/Level2-tag/Level3-tag
Your structure include the following namespaces: "vehicle makes", "models" and "trims" and each of those contain a hierarchy of tags.
You want the user to navigate it like that:
Go to the first filter, "Vehicle makes", type in something and get ONLY autofill resposes of tags that are existing as a tag under the namespace "vehicle makes"
Then the user has to go to the next filter "models" to then type in something that has to be an available tag option in models and so on...
If this is your desired outcome - please try this:
Go to your admin search rail and create create 3 tag filter predicates.
Set their root path, each to their dedicated namespace and name the filter accordingly.
"vehicle makes" to /content/cq:tags/vehicle-makes
"models" to /content/cq:tags/models and so on...
Now the user has 3 filters, which only give autofill responses based of the root path of that filter and the available tags within that structure.
If i got you wrong, please tell me where i have lost you.
You have understood me correctly. Let me get this information to the team so we can test it out. Thank you.
We did some testing with this. The one challenge we found at the moment is that your approach works for the filters but then on the properties side we have to tag everything in the tag field. Are we able to apply a the root path of the tag to a custom field in properties as well. We'd like to enforce some mandatory fields in properties and thats very difficult to do if people are only tagging in the tags field.
Progress! We turned the search predicate problem in a metadata schemata challenge
This might have then turned now into something else and you might get more and better feedback from the community if you open up another tread. I also might add that from here, there are a looooot of options you could archive this with.
So it becomes very hard to give you the best way to do it - based of your descriptions of the situation you gave so far.
Relevant information for me would be - a better understanding of what you need and how you want it to be archived.
Give an example of your assets/folder structure / your naming standards / the way you want to enforce the mandatory fields...
Are the assets vehicle make + model + trim - OR is it possible that an asset is only one of those or a combination of only two of those options?
Is your folder structure already made to reflect one of these aspects?
Could you then create multiple metadata schemata - each specific for each tag root path and have the folder structure accordingly?
Or is there the option for you to ask your developer to create a workflow that fills in the checkboxes, the tags, etc. based of a combination of the folder structure, the filename, other metadata you might already use?
For this tread, i believe - my approach is already the right answer - and you should open up a new to get better responses.
@dmescia2 Did you find the suggestions from Adilos helpful? Please let us know if more information is required. Otherwise, please mark the answer as correct for posterity. If you have found out solution yourself, please share it with the community.
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies