Visible values in "Search All Issues" Status value list - bug or wrong config?

Janet Beckmann1

Hi,

we have a problem with the "Search all Issues" page: there are too many values displayed in the status column.

When a jira user open the Search view "Issues" -> "Search All Issues" she will have the standard search page displayed. By default there is no preselection for the Search Column values, so it will be Project: "All", Type: "All", Status: "All" and so on. In the dropdowns columns we have the following:

The user sees / can select the Project(s) his user group is assigned to (good).

She sees / can select only the Issue types used in these projects (good).

IS: She sees / can select all the possible Statuses in the system (bad)

SHOULD BE: Sees only the statuses used used in the workflow schemes of "her" projects (same as in "Types").

When selecting her project(s) in the first column, the unused statuses are not visible anymore. Having only one project this should be the same list for "All projects".

To see a long list of unknown statuses is very confusing for a user and is useless anyway as Issues in her projects can not have these statuses.

What is wrong here, I checked all the configuration and Q&A.

Please advise.

Thank you, Janet

__

we are using Jira v6.2 for different Customer Helpdesk as well as internal development projects. Consequently we have 2 or 3 different workflows for these different projects, using different statuses. Say workflow 1 uses statuses A, B, C and D. workflow 2 uses statuses A, D, E and F. We are using different issues types as well.

Nic Brough -Adaptavist-

You haven't done anything wrong. The reason it does this is that the list of status is global, and your users *might* need to see the status.

There's simply too much work involved in limiting the list. Thinking it through, the code (which isn't the problem) is going to have to take the list of projects the user can see, read each one for the workflow scheme, read each workflow in the scheme to get the list of status and sue that. It's not going to be quick to run. Presenting the entire list as configured is far more simple.

Bear in mind that this compounds as well - status is the most complex, but if you're going to try limiting the drop-downs to maybes, you'll need to impose similar workloads for every select, multi-select, user, radio button and check-box field...