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

Question

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.

Tarang · Answer

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.

Deniz Oğuz - The Starware · Answer

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.