[#JRA-9367] Custom Fields Visibility in the Issue Navigator

JIRA

Custom Fields Visibility in the Issue Navigator

Created: 15/Feb/06 05:34 PM Updated: Thursday 05:52 PM

Component/s:

Custom Fields, Issue navigator, UI / Usability

Affects Version/s:

None

Fix Version/s:

None

Time Tracking:

Not Specified

Issue Links:

Duplicate

This issue is duplicated by:

~~JRA-13683~~ Don't hide columns in the issue navigator

~~JRA-15005~~ Show custom field in search when searching in multiple projects/contexts

Reference

This issue is related to:

~~JRA-13391~~ Project-specific custom field columns don't show when "All projects" selected

Participants:	amanda king, Bogdan Dziedzic [Atlassian], Chris Mills, David Bullock, Dorothee Wienert, Ernest Wong [Atlassian], Jenny Jones and Nicolas Brough
Since last comment:	1 week ago
Labels:

Description

« Hide

Custom fields which are issue type or project specific are not shown in the issue navigator until the relevant project or issue type is selected (and refreshed via the blue box). This could potentially be a bit confusing for first time users.

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

Dorothee Wienert added a comment - 11/Apr/07 06:15 AM

It is not only confusing myself, it is annoying me a lot!!! I need many filters at the moment to cover all the different types with all the different columns/details. But for getting the best overview you can/could have in a project, it is neccessary that you can create for example one filter for all bugs and change-requests together with all columns you want to see (even if they exist just for one type)!
I vote to fix this!!! Thank you.

[ Permlink | « Hide ]

amanda king added a comment - 17/Jul/07 01:43 PM

In addition, if i select multiple projects, i would like all fields, including custom, to appear for filtering. if differing data, put it all in there.
for example, the version field, if i select more than one project, put both project's versions in the dropdown in issue nav

[ Permlink | « Hide ]

David Bullock added a comment - 31/Oct/07 11:11 PM

This is very counter-intuitive. If the field is configured to be displayed behaviour should be "show if any issue type using this field is included in the issue list". If I don't want it, then I'll turn it off, thanks. The existing behaviour of "show field only if ALL issues are of the expected issue-type" effectively makes me choose between viewing the columns I want versus viewing the rows I want.

[ Permlink | « Hide ]

Jenny Jones added a comment - 17/Jun/08 09:43 AM

I know JIRA is looking for the intersection of search criteria and everyone can understand when versions don't show up for searches on multiple projects. But the custom fields and issue types are particularly contrary to the average search user.

It would be so much easier if you would make custom fields and issue types available across all searches, regardless of the specific criteria set.

In these two cases, the union of choices makes more intuitive sense than the intersection of choices as is the case for versions and components.

[ Permlink | « Hide ]

Chris Mills added a comment - 25/Aug/08 08:37 PM

This one drives me nuts, to get some fields to show in filters I have had to make the custom fields global which isn't the best (especially when dumping all fields to excel since you get a lot of extra rubish. Agree entirely with David Bullock's comment:

"show if any issue type using this field is included in the issue list". If I don't want it, then I'll turn it off, thanks. The existing behaviour of "show field only if ALL issues are of the expected issue-type" effectively makes me choose between viewing the columns I want versus viewing the rows I want.

[ Permlink | « Hide ]

Bogdan Dziedzic [Atlassian] added a comment - 03/Sep/08 05:48 PM

for ref https://support.atlassian.com/browse/JSP-27556

[ Permlink | « Hide ]

Nicolas Brough added a comment - 06/Oct/08 05:23 AM

This the biggest problem we have with filters here at the moment (even the "can't search for empty fields" problem is a distant second place). We've had to implement (bad) reporting outside Jira just to get round this issue.

I can understand the logic behind it, but for 99.99% of users, it's not just counter-intuitive, it's simply wrong - there is data there (for some issues), and Jira is deliberately hiding it, for no benefit.