Just a heads up: On March 24, 2025, starting at 4:30pm CDT / 19:30 UTC, the site will be undergoing scheduled maintenance for a few hours. During this time, the site might be unavailable for a short while. Thanks for your patience.
×Hallo Atlassian Community!
I am in the process of customizing a Jira instance for a customer. I stumbled on a roadblock when trying to rename labels of fields in the instance. Any help or suggestions on how to solve this problem would be appreciated!
Context:
Requirement:
I need to rename the Issue Types, Custom Fields and System fields on Project-level (not instance-level). Built-in Jira functionality like Epics should not break by making this change. The renaming should be visible for all parts of the project, i.e. issue creation, editing issues, viewing issues.
As an example, I want to rename:
What I have tried
Using ScriptRunner's Behaviours, I have added behaviours that set the labels of the fields I want to rename. Here is the code I used to achieve this:
// get the fields
def epicNameField = getFieldById("customfield_10003")
def epicLinkField = getFieldById("customfield_10001")
def summaryField = getFieldById("summary")
// rename the fields
epicNameField.setLabel("Phase Name")
epicLinkField.setLabel("Phase Link")
summaryField.setLabel("Name")
Doing so actually works great when creating or editing an issue (See Image 1). This approach does not work in the Issue View, however. (See Image 2)
Any help would be greatly appreciated!
Kind regards,
Simon
-----------------------------------
Images
1.
2.
I completely agree with @Leonard Chew - renaming fields by project is a nightmare and leaves your people with a disjointed and inconsistent system. You also can't do it in many places, and a lot of Jira users will be working outside the context of a project so you can't know what label to display.
Simple example, imagine your Summary/Name rename (I probably have issues with the poor choice of word there as well, but that's not important here). It's name in project XYZ, Summary everywhere else.
On a related note, do not rename Epic. The three main Jira applications are ok with it, but some apps fail in interesting ways if you do. This is going to be fixed soon, so you will be able to rename it (although it might only be as "feature" to fit in with Jira Align)
I would strongly question the desire to rename fields like this.
There is one other thing you might want to do - change the field names by person, not project. Years ago, I brought a document tracking system into Jira and the team needing it struggled with the names of fields. So I built a language pack for them and asked them to switch their language from English to English (for docs).
Thank you for your answer and sharing your view. As I commented on @Leonard Chew 's reply, I see your point. The "user-level" custom language pack is definitely an interesting approach, which I will try out! I saw there is an "InProduct Translator" plugin, which should make the process relatively smooth (I hope).
Thanks for taking the time to answer!
Simon
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Simon, before answering your question, I'd like to give my opinion on this:
I suggest to keep all field names as they are and instruct the users how to use the corresponding epics in your context.
If you search for the fields with JQL, you will need to search for "Epic Name" and so on, so even if you fake the labels, the fields will still be the original ones and that will probably raise many questions and maybe bugs.
Anyway, that said, here is a possible solution to change the labels on your issue screen:
I have written a post how you can use web-fragments to change screen information by injecting javascript.
You will be able to change the labels like this, but again... I suggest to inform the users how to use the epics in your context and leave all the names as they are.
Cheers
Leonard
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thank you for your answer and sharing your view. Definitely makes sense! I will likely attempt a solution that does not include Epics and instead create my own Issue Types (The functionality Epics provides seems less important for this project). This combined with the "Custom Language" @Nic Brough -Adaptavist- mentioned might make a good solution.
Thanks again for your time!
Simon
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.