Project

General

Profile

Forums » Open discussion »

Scope of issue autocomplete in text fields

Added by Jan Krutisch 1 day ago

Due to a user request in our organisation I just spent a few minutes trying to figure out how the issue autocomplete works when you type # or ## into a text editor. Currently these are scoped to the current project only. I wonder if there's a reason it doesn't use :scope => (Setting.cross_project_issue_relations? ? 'all' : nil) as some other places use? Is it an oversight or maybe for performance reasons? Ideally, I think I would want to use the Setting.cross_project_subtasks setting, but I guess that would be confusing.

(I guess an additional question would be why Redmine distinguishes between these two settings, as I think it would be really helpful to have the granularity of the latter available for any issue relations and not just subtasks as well, but I don't want to complicate things)

Thanks,

Jan


Replies (1)

RE: Scope of issue autocomplete in text fields - Added by Holger Just 1 day ago

The cross_project_issue_relations setting in fact controls the ability to add issue relations (i.e. "connections" between issues). It does not affect the ability to add links in text fields.

Similarly, the cross_project_subtasks settings only controls the ability to add sub-issues to a parent issue on a different project. It does not affect the ability to add textual links.

The autocomplete scope is generally set in some places to allow a autocomplete in specific form fields, such as the form to add a new issue relation and to scope the search according to the fields semantics.

With that being said, one could in fact argue that the autocomplete in textilizable fields should always search over all (visible) issues in all projects as we can also link there in the end. This could be implemented by removing the project_id: project argument to the auto_complete_issues_path method in ApplicationHelper#autocomplete_data_sources.

This change however could result in more potential "clashes" if other projects have matching issues since we only return the first 10 issues ordered by issue ID (highest first), thus "drowning out" results from the current project which may often be more relevant.

A workaround could be to adapt the AutoCompletesController#issues action when no scope is given. Here, we could to first search in the given project and (if there are fewer than 10 matches) to try again in other projects. In any case, unless a numeric id was given here, we do perform a LIKE search over the issue subjects which may be expensive if there are a lot of issues (in the current project or the Redmine instance in general).

Generally, I think it may be worthwhile to propose this change as a feature issue.

    (1-1/1)