File Category Search and Filter: Tabular file tags are not searchable on file tab of a dataset and do not appear in the tag filter selection as other file tags do.

[kcondon]

1. Add a tabular file and a non tabular file for comparison.
2. First set either custom or default file tags that are not tabular, ie. documentation, data, code, or custom1, etc.
3. Next, after tabular file is ingested, add a tabular file tag such as event.
4. Now, in the search box on the file tab, search for your non tabular tags, notice they filter the file list on the file tab, file table.
5. Try searching on a tabular tag and notice it is not found.
6. Next, select from the tag filter select list any of the non tabular tags, notice they also filter the list and that tabular tags do not appear.

[landreev]

FWIW, tabular file tags are not "categories", strictly speaking. It's a different thing, even if we display them in a similar way in the UI.
Whether they are indexed in solr, or whether there was a design decision that they should be searchable the same way as file categories, I don't immediately remember.

[landreev]

OK, they are indexed, under a different solr field:

// TABULAR DATA TAGS:
// (not to be confused with the file categories, indexed above!)
for (DataFileTag tag : fileMetadata.getDataFile().getTags()) {
     String tagLabel = tag.getTypeLabel();
     datafileSolrInputDocument.addField(SearchFields.TABDATA_TAG, tagLabel);
}

(from IndexServiceBean.java)
The field does not appear to be exposed via the advanced search form. Again, I don't know whether the intent was to make both the category and the tabular tag searchable via "File Tags" in that form; but as implemented, it only searches on the category.

Let's search through the older issue some more... I feel like these category vs. tab. tag. issues keep coming up with some regularity.

[kcondon]

OK, terminology aside, it seems to me that the goal is to allow a user or an admin to quickly search on or filter a file list based on some labels, regardless of their underlying technical implementation. I've updated the title. I did do an issue search prior to opening this and felt I'd done enough in that regard. If it keeps coming up, maybe that also tells us something? Maybe @scolapasta recalls. The only thing I remember is they were implemented separately, perhaps with slightly different original intentions but when design streamlined them into appearing in the same conceptual file tag role in the UI, their separate implementation results in ongoing questions. Probably nobody wanted to touch integrating them?

[landreev]

OK, terminology aside, it seems to me that the goal is to allow a user or an admin to quickly search on or filter a file list based on some labels, regardless of their underlying technical implementation.

Do you actually remember this being explicitly discussed? And that it was decided that it should be implemented like the above? I agree that these tags should be searchable, like everything else. But it's not obvious to me that we want to mix the two together, in the same search field on the form. They really are quite different, not just in implementation, but they describe somewhat different things. So I can see how it could make more sense to add a dedicated search field, just for tabular tags. (actually, the word "category" would be more appropriate for these - since they are pre-defined and fixed)

I'll bring this up with the team.

[kcondon]

It looks like as part of the dataset page redesign there is a document and discussion around file tags. There are various large issues with bulleted lists of changes and some parts pulled out, discussed, moved forward, so a bit tangled. I did see this:

#7082 (comment)

and that issue refers to some others containing more and more info. Seems like it was generally acknowledged the area needed cleanup and work and shorter term filtering and searching was enabled on dataset page for tags, for tabular tags, adv search was proposed in the short term? Longer term, it appears perhaps a part of the overall dataset page redesign so not sure whether it is explicitly identified or what.

[kcondon]

Closing in favor of: #7082 (comment)