Do we need any special permissions to unlock a locked field? E.g. Epic Name

[Fox Chen]

We need Epic fields to apply to a new Epic issue type, however, Epic fields are locked, we cannot add the issue type into the context at application level.

I see the document  https://confluence.atlassian.com/jirakb/how-to-unlock-a-locked-field-779158866.html.

We would like to know if any special permission to possibly unlock a locked field at application level or to run those queries?

Additionally, in the documentation, it mentioned:

These fields will be locked again on startup by automated tasks within plugins.

What does it mean?

Thank you.

[Alexey Matveev · Accepted solution]

Hello,

There are no special permissions to unlock a field. The only way to do it through the database. Database access is only allowed on Server, which means that you can not unlock a field on Cloud.

And if a field is locked, it means that the developer of the app, who added the field, decided, that this field should never be changed by a user, and if the developer did that, there were reasons. That is why do not unlock locked fields.

[Fox Chen]

Hello Alexey,

Thanks for the answer. But do you know "These fields will be locked again on startup by automated tasks within plugins." What does it mean? If it means as soon as Jira restart, the fields will be locked again? This is done without any other plugin needed, right?

Should be no harm to apply the locked field to a new issue type, right?

[Alexey Matveev]

If plugins have such automated tasks then the fields will be locked after start. For Jira Software it will not be locked. At least I already unlocked this field and on startup this field stayed unlocked.

The Epic Name field by default is available only for Epics. You should not add it to other issue type, it can influence the work of Jira Software. Better create a new field and use it for other issue types.

[Fox Chen]

We have 2 issue types for Epic, but Epic fields only applied for one of them which I don't know why it setup in this way by former admin.

Creating a new field is possible to make the new Epic type working like the other one? My problem is actually the issue with new Epic issue type will not show in Epic Panel and the Epic link. So Epic fields are NOT mandatory to make Epic issue working as expected?

[Alexey Matveev]

You should leave only one Epic type. Find the Epic type, to which the Epic Name is associated, then convert issues of the other Epic issue type to this one. Try to convert a single issue first and have a look that all Epic links stayed untouched. Then you can use the Bulk Move feature.

[Fox Chen]

May I know if any impacts we have 2 Epic types? 

[Alexey Matveev]

As you can see, some fields are not associated to the other issue type. I personally never had 2 Epic issue types. I had it once in a system and had the same problems like you. Then I got rid of the one of the Epic issue types and everything worked fine. 

Jira Software is not supposed to work with 2 Epic Issue types. You can try, but any bugs you find, you will have to solve yourself, because you are using Jira Software app the wrong way.

[Nic Brough -Adaptavist-]

You will find your second "Epic" type does not work the same way as the main Epic type.  Jira Software expects there to be a single Epic type and simply won't recognise a second type.  So there's no real "impact" beyond "it won't be treated as an Epic"

And, don't unlock the fields, they're locked to stop you breaking things.

[Fox Chen]

Hi @Nic Brough -Adaptavist- , yes, because users want to have new name on the Epic Type beyond the old one, I just wanna add the new Epic type to the context of these fields.

[Nic Brough -Adaptavist-]

Ok, let me put it more simply: do not do this, it will not work.

It will not break badly, but your new issue type will behave mostly as a standard issue, not as though it is an Epic.  Your users should use Epics when they need Epics.

[Fox Chen]

Yes, thanks @Alexey Matveev  @Nic Brough -Adaptavist- for the suggestion.

I won't do anything at the moment, might try to convince my users first.