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; } } }

GreenHopper Field becomes required in Fieldconfigurations after JIRA restart

Udo Brand

Hi,

I'm currently setting up a new project in a JIRA environment where also GreenHopper is in use. I set up four field configurations for four new issue types. Now everytime JIRA gets restartet I see that the GreenHopper customfield Epic Name becomes required in those field configurations.

Since we also use exocet-lite for creating linked issues in postfunctions, this is painful due to the fact that creation of those linked issues now fails due to a non mapped required field (Epic Name).

Has anyone an idea why this field becomes required after JIRA restart and what we can do to stop this.

Thanks, Udo

Accepted answers

pkirkeby

That is expected since the field is a Greenhopper managed field. On restart, it is detected that the field has been modified and it gets re-configured.

All comments

Justin Leader5

Check this out, you can unlock that field:

https://confluence.atlassian.com/display/GHKB/How+to+unlock+a+Locked+field

Udo Brand

Hi Justin,

we already unlocked the field in order to set it optional. But after JIRA restart it becomes required again (still unlocked).

Justin Leader3

Did you unlock the field via the normal field configuration or did you go into the backend database like that article recommends?

Udo Brand

It was unlooked via SQL as described in the article, since you can not do it in the field configuration.

pkirkeby

It sounds like you are running into this problem here:

https://confluence.atlassian.com/display/GHKB/Epic+Name+field+is+required+on+Create+Issue+Screen+for+other+Issue+Types

Udo Brand

hmm, you answered my question with my own question?

pkirkeby

I updated the link. copy-pasta fail

Udo Brand

Thanks Pelle,

We had initially the problem that Epic Name was required and locked in the field configurations, yes. We unlocked the field as described. The difference is in our case Epic Name was only in context of issue type Epic.

The question is, if we lock Epic Name again (this is what we have not done) will it remain optional in the field configuration after a JIRA restart?

pkirkeby

That is expected since the field is a Greenhopper managed field. On restart, it is detected that the field has been modified and it gets re-configured.

Udo Brand

Thanks Pelle,

that was the part that I didn't understand.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-software

field-configuration