View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0019302||mantisbt||filters||public||2015-01-30 01:42||2018-09-12 03:34|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0019302: Free text search should match against tags|
I've noticed that if I put in a tag in the free text search field, i get N entries. But if I put the same tag in the tags field, I get > N matches. This means that we are not doing text search against tags.
|Tags||No tags attached.|
|has duplicate||0011976||closed||cproensa||Search by Tag|
|related to||0007183||acknowledged||new search function on field and custom field|
|related to||0024750||acknowledged||Allow text entry for search with partial match in custom fields filters|
|related to||0011467||new||Bug view page search within customized fields|
What's the rationale for searching tags via text search ?
IMO, free text search applies to text fields, so it makes sense that tags are not covered. If a user wants to search by tag, they should use the dedicated field.
Typically free text search is a way to look across all aspects of an item. This includes content, meta-data, etc. Searching via tags, will just give tags.
Currently it covers the following fields:
The question is whether we should add not just tags, but:
i.e. almost search everything vs. just few pre-canned fields. Think of it as the Bing/Google of the bug tracker.
It seems, it will not be implemented in matisbt directly.
Not sure if this can be done with current approach for searching.
Whenever someone should start working on that, keep in mind what I commenetd in PR https://github.com/mantisbt/mantisbt/pull/1140#issuecomment-320712837
Strange result, as I got what I expected on one of my test systems.
Independant from that, there is a serious conceptual issue.
E.g. set Read Access of a custom field to access level manager.
Agree, including tags, custom, fields, etc in the filter search needs more logic to account for user permissions on viewing those items, on a project, or issue level.
Additionally, i'm not sure the approach of "search everything" is all that good.
Yes, best solution would be to have a dedicated search plugin, with al lthe advanced functionality, and keep native search more or less simple as it is now...
A workaround might be to allow free text entry into the tags and custom field filters rather than just a drop down box option. 0024750
|2015-01-30 01:42||vboctor||New Issue|
|2015-01-30 03:04||dregad||Note Added: 0048739|
|2015-01-31 21:08||vboctor||Note Added: 0048757|
|2017-08-03 09:57||hloehnert||Note Added: 0057383|
|2017-08-05 15:37||atrol||Note Added: 0057399|
|2017-08-05 15:44||atrol||Note Added: 0057400|
|2017-08-06 08:36||atrol||Relationship added||related to 0007183|
|2017-08-08 03:17||atrol||Note Added: 0057412|
|2017-08-14 18:37||cproensa||Relationship added||has duplicate 0011976|
|2017-08-16 14:12||cproensa||Note Added: 0057482|
|2018-09-11 13:50||sandyj||Note Added: 0060639|
|2018-09-12 03:33||dregad||Relationship added||related to 0024750|
|2018-09-12 03:34||dregad||Relationship added||related to 0011467|