nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Unable to hide 'Epic Link' field via Field Configuration?

M_S_

Normally, visibility of fields in JIRA is configured with Field Configurations and Screens. The field needs to be configured for the issue type and for the screen to become visible.

I have different issue types in my project and they have different field configurations, each selecting a subset of applicable fields. The screen configurations (e.g. create issue screen) are not issue type dependent and include all fields.

This works well with pretty much all fields, so only those applicable to the issue type are shown.

However, 'Epic Link' can apparently not be configured this way and I am puzzled about the restriction. I want to use Epic Link for some issue types, but not for all. How can I hide it without duplicating all my screens?

Accepted answers

All comments

Scott Theus

I've wracked my brain over this and the short answer is that I don't think you can without at least setting up a screen scheme for the "Epic" issue type. From there, add a custom check box for "Show Epic Link" and some conditions on the Epic Link field to only be visible when that box is checked.

-Scott

M_S_

Not sure I understand that response. Why would I need a checkbox? Perhaps my question was misleading. I want the Epic Link field to be shown for some issue types, but not for others. I do not need to differentiate between issues of the same type.

It puzzles me that I can do this with all other JIRA standard fields (well, except what is obviously mandatory) as well as any custom field, but not with Epic Link. I do not see a reason why Epic Link would need to be so special.

How can this be raised to Atlassian's attention?

Scott Theus

Ahhh...I understand. I tested it and ran into the same problem. I created a new issue type screen without Epic Link and a screen scheme that included it, using Create, Edit and View for that type with the new screen. The Epic Link field remained available in each function.

I suggest raising it as an issue by clicking the create button and reporting it here:

https://jira.atlassian.com/secure/BrowseProjects.jspa?selectedCategory=all&selectedProjectType=all

If you don't mind, post a link to the new issue in this thread, I'd like to watch it.

-Scott

M_S_

I would, but that page does not let me create a new bug report. Instead it leads back to the forums.

How do I raise a bug/support request (I am on a 10 ppl starter license)?

@AnnWorley is that something you can look into?

I should add that it seems that you went through screen schemes, whereas I tried it through issue field configurations. Neither seemed to work.

Morgan Knicely

Because Epic Link is a System Field, not a Custom Field, it cannot be configured per issue type using either Field Configuration or Field Contexts. This is the same with configuration of other System Fields such as Priority and Resolution.

In other words, with Jira Software installed, all non-subtask issue types will have the ability to set the Epic the issue is linked to. The only way to suppress this for a given Issue Type is by not including it in the Create/Edit/Other screens for that issue type.

The Epic Link field is Locked:

The Epic Link field does not have a "Configure" option. It only has links to change the Screens that it appears in:

Cheers,
Morgan

M_S_

@Morgan Knicely: thanks for the response. I understand why the field cannot be hidden as it is a system field and therefore treated special. The problem may therefore not be an 'implementation bug', but a design issue. Why should the software prohibit hiding the Epic link field through field configurations?

As stated in the original post:

This works well with pretty much all fields, so only those applicable to the issue type are shown.

However, 'Epic Link' can apparently not be configured this way and the restriction feels entirely unnecessary. I want to use Epic Link for some issue types, but not for all. How can I hide it without duplicating all my screens?

Just one example: showing the epic link field for epic issues while showing a message that it is not applicable in this context is bad UI style.

Create Epic Issue.png

Can you elaborate why it needs to be this way, rather than why it technically is this way?

As a consequence, I would need to duplicate my create issue screen ... and my edit issue screen... and a number of workflow screens, just to have one version with and one without the Epic link field. Feels wrong.

Jason Kemp

A year later, but while M.S. should be creating screens for the create and edit actions for each issue type--I still wish we could configure the Epic Link in the field schemes.

My use case is a special project within our Jira that is used as a "trash" project--it's literally called that. Rather than allow deletion of issues, all users can move issues into TRASH but nobody but system admins can see them. Moving something to TRASH is, effectively, the same as deleting it for the end user. This is so issue "deletions" can be reversed if necessary.

However, this can cause a problem when issues have an epic link when they are moved to the TRASH project. Our workflow checks require all child issues of an Epic to be done before the epic itself is finished; it would be nice to hide the Epic Link field in this project so the value is automatically stripped on move.

Michael Aglas_dd9h0h

The explanation makes no sense... I can also hide system fields like Description, Summary, Priority, etc. via field configuration... so why not Sprints?

Also it is a locked customfield not a system field, as it is listed in the Customfields section, but locked there

The way Atlassian implemented the Jira SW fields is misfortunate. I have multiple Screens and schemes matching for many projects and issuetypes, so I could easily add the Sprints field everywhere and decide via the field configuration if a project uses Sprints field or not. That would be just a field configuration in addition. But this way I need to copy alle the Screen schemes and Screens and add everywhere a single field... This is a mess! So if I add another field to the original screens I need to not forget to re-edit also the "Scrum" Screens. This is a nightmare!

An even better approach would have been to define an individual project type for Scrum projects. So I could control via this if I will have the Scrum fields available or not.