Improving the visibility of advanced custom fields would be a valuable enhancement. We conducted usability testing on Jira DC (for our Dynamic Forms app), where the experience of selecting advanced fields is similar to that of Jira Cloud. The findings indicated that users had difficulty locating specific fields by changing categories via the menu on the left. Thank you for pointing out this issue @Frank Polscheit @Barbara Schwarzwald [Decadis AG]
One more question - @Carol Low, why aren't these changes available in the Jira Labs environment? It’s a very useful panel for testing and - if needed - disabling features during the beta phase.
I would love to see more work around re-mapping duplicated fields to a different field. For example, someone created a field called "Due Date" instead of using the system field "Due date." I would love to be given the ability to delete that field and have the UI ask me if I want to map the field to a different one, assuming they are of the same type.
Also, it would be nice to extend the context concept to the system fields. Examples would be Description and Resolution. We have groups that want specific values for the Resolution field, so we end up with 20 different resolutions (because Jira Software and Jira Service Desk share this field now that they are under the same umbrella). It would be nice to set up different contexts for the different projects to allow for their own list. For Description, I believe that this was available in Jira DC, where a context could be set to have a template for the Description field for certain projects.
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
I wish I could like @Deidre East's comment a thousand times. Merging "duplicate" fields is one of the headaches inherent in consolidating multiple Jira systems into a single system after an acquisition. Any help you can offer in this situation would be most ... helpful!
On the Fields site, when selected all 7 available columns, there is no way to see them all at once, unless you manually change the width of the column. Is that correct? Or there is a workaround for this?
Also if you adjust the column width and then reload the page, it all goes away and you don't see the columns again, so every time I open the page, I have to manually adjust the page.
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
I have a few post functions, that have some conditions refering the customfield ID.
It would be very helpfull to be able to filter by customfield id. It is a PITA to show the customfield ID collumn, then scroll down to the last field and then use the browser search functionality to find the custom field...
Drag and drop of columns doesn't work with Edge. It shows the dragging symbol, it shows the drag, but it doesn't let me dropit. Is that a wanted behaviour?
Also it would be nice to find the option ID of e.g. a multipe choice field easier. Atm we have to "edit" the option to find it in the page address above.
Hi @Carol Low , how can we get access to the new Customfield experience?
also, I can only agree with @Deidre East , we are currently merging many duplicate fields with over 110k datapoints in need of change (from field A to field B). We cannot complete with bulk or automation, we need to pay someone to create scripts respecting rate limits transferring the data and validating the output :(
An absolutely long awaited, much needed enhancements to how administrators can manage fields. This thread seems to focus on UI and that's great. I have one request related to algorithm used to create custom fields. Please review this within your product team and I'd also love to hear what community thinks about this. If there is another blog to push this request, please advise.
So here we go...
PLEASE do NOT allow admins to create custom fields if it meets any of these criteria.
It conflicts with a reserved keyword. e.g.
"type" is a reserved system keyword that can be used in jql and alias for "worktype" (fka "issuetype")
"category" is also keyword (part of project detail "Project category") and can be used in jql.
And..... there are probably more keywords like this
If the system or custom field with identical (or similar) name already exist. e.g
If there is field "abc-xyz" then do not allow creating "abc xyz". At least alert the admin about similar named fields to help them. We are in AI world and this should be piece of cake
All other Jira features like export/import, C2C, JCMA, etc currently seem to have free ride in polluting the fields table. e.g.
Legacy export/import via CSV creates a bonus NEW custom field "External System ID"
Fields that get created by OoB templates, plugins, etc.
It seems these fields are often LOCKED fields. If the decision is to NOT buy the plugin then those fields cannot be deleted. It is like permanent garbage in the system
65 comments