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

[Janet Beckmann]

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- · Accepted solution]

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...

[Nic Brough -Adaptavist-]

... although I also should have said - it would be nice if it could do this!

[Janet Beckmann]

thank you very much for your prompt reply.

Yeah I kind of supposed it was like this...

I thought after all it is an sql join but ok, it could be really slow. I am not sure what you mean with "try limiting the drop-downs to maybes"..?

Anyway I read there is no way you can customize the built-in searches as such... but simply pre-selecting the values in the projects dropdown would solve our problem. Then the dropdown shows only the available statuses. Do you know about a plugin or a way we can customize the html for the global search page?

[Janet Beckmann]

thank you very much for your prompt reply.

Yeah I kind of supposed it was like this...

I thought after all it is an sql join but ok, it could be really slow. I am not sure what you mean with "try limiting the drop-downs to maybes"..?

Anyway I read there is no way you can customize the built-in searches as such... but simply pre-selecting the values in the projects dropdown would solve our problem. Then the dropdown shows only the available statuses. Do you know about a plugin or a way we can customize the html for the global search page?

[Nic Brough -Adaptavist-]

It's not a simple SQL join for status - although you can start from "projects user can see", you'd join the workflow schemes, to get a list of workflows. But then you'd need to open every single workflow in their plain XML, parsing each one for the IDs pointing to the status, and then use the resulting list to read the list of status.

So it would be quite a lot of work.

Anyway, yes, you're right, there's no way to customise the searches - they're quite open and flexible to allow a lot of power to the users.

I'm aware of one chap who tried to write a plugin to do this, but it was unusable once more than a dozen projects were set up, for the reasons above. He never manged to optimise it. I don't know if anyone else has had more luck.

[Ronny Freigang]

Thanks for sharing the information with us. Could you give some more information why this issue is no bug? From my point of view it does not make sense to offer all possible status for search when a user cannot access projects that the (workflow or) status does refer to. Sure it is valid to name the reasons why it is not implemented in another way. But being a software engineer myself, I see no reason not to work on this issue.

Consider a big company with a lot of custom workflows that are used in internal project and a large number of external customers that have a very restricted view on their projects. Why should we bother them with status that do not matter to them. The more custom workflows we have, the more the customers get confused. In addition I would like to use the same name of status in different workflows. Having more then one of these status, both of them will occur in the dropdown list, making it almost impossible for someone who does not have the background knowledge to choose the right status.

Do you know if this has been filed as a JIRA bug already?

[Nic Brough -Adaptavist-]

It's not a bug - the software is working as designed. It is an improvement. I'm not sure there's a lot of value in it. At the moment, the search says "look through the list of status". What you're asking for is "look at list of status, read the user's browse permission for every project, read the projects workflow schemes to work out what workflows are in use, read the workflows to find out what status are used in them and cut down the status list to just those". That's complex, big and frankly, not worth the bother. Especially when the default setup for JIRA is "everyone can see everything", and you have people who will be asking you "I know issue X is in status Y, but you can't search for it". As I said before, I've seen someone try to write a plugin to do this, and it simply fell over on the complexity.