Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

How does Jira resolve name space conflict between native types & fields to custom types & fields?

Tarang
Contributor
October 3, 2019

This question comes up for me as in a very large organization with hundreds of projects and teams, the Jira admin over time have introduced custom fields and types that don't or didn't exist in Jira and now they do are will likely do in a future release.

For instance types like Theme and Initiative don't exist as native type in Jira version 7.13.  We have created custom types for this as we have created custom field for Team.

However, I know Jira Portfolio has both of these as native type and field.

[Q] How does Jira resolve name space conflict between native types & fields to custom types & fields?

  I imagine conflict being resolved when one views project & issues in Jira Portfolio. 

  This conflict could appear from Jira Portfolio if one is creating Theme of Initiative there and propagating changes into the Jira project.

 Has anyone encountered similar issue?

 It is a matter of future proofing use and behavior in relation to the product evolving as like all product do.

1 answer

0 votes
Deniz Oğuz - The Starware
Rising Star
Rising Star
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.
October 3, 2019

There may be multiple custom fields with the same name. Jira will not complain but your users may have difficulty in identifying which one refers to which field when they see multiple fields with the same name. 

As far as I know, Portfolio no longer creates "Theme" and "Initiative" issue types by default. Instead it allows you to configure hierarchy yourself by selecting corresponding issue types. Also it is very easy to rename existing issue types whenever you want. You may need to update some JQLs.

Tarang
Contributor
October 4, 2019

Thats just it, if it doesn't resolve the conflicting names then the left hand may not know what the right hand is doing so to speak.

There ought to be an enforced convention that explicit forbids overloading names and claiming these as system names and any custom name is prefixed for example "CF_" or "CT_" iinfering CustomField or CustomType.

This helps users and avoids the trap admins can fall into.

Suggest an answer

Log in or Sign up to answer