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:

• Summary
• Description
• Steps to reproduce
• Additional Information
• Issue notes.

The question is whether we should add not just tags, but:

• Tags
• Categories
• Custom fields
• issue ids
  etc

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.
Any suggestion how to implement it by a plugin?

PR https://github.com/mantisbt/mantisbt/pull/1140

i.e. almost search everything

Not sure if this can be done with current approach for searching.
We might need some kind of inverted index, or use something like Elasticsearch / Lucene.

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.
It's been about 6 times slower after the changes when searching by text.

Independant from that, there is a serious conceptual issue.
After the changes, you are able to search based on data where you are not allowed to view the data.

E.g. set Read Access of a custom field to access level manager.
Log in as a developer and search by text.
You will see issues in the list where you are not allowed to see the custom field.

After the changes, you are able to search based on data where you are not allowed to view the data.

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.
This would add a lot of complexity to an already complex filter query.

Additionally, i'm not sure the approach of "search everything" is all that good.
Ideally, i'd like to choose what items to search on: description, notes, tags, custom/plugin fields
(note that plugin fields are not stored in database!)

Not sure if this can be done with current approach for searching.
We might need some kind of inverted index, or use something like Elasticsearch / Lucene.

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
But IMO custom fields should be searchable in free-text search.

AGREE that custom fields should be searchable in free-text search. This is a huge problem for my users. They're very confused by inconsistent search results.