Hello Atlassian

I just wanted to express my support for this topic. Apologies if my comment is redundant to stuff that already has been said. 

IMHO, Team-based projects pretend to create a sandbox for all settings, i.e. everything you do only affects that very project and so it is ok, to delegate the right for these team-based projects to more people than a few Jira administrators.

And yet as a Jira administrator, every month I have to search team-based projects that for unknown reasons were configured with fields like "Labels (Dropdown)", "Team (Text)", Priority (Dropdown). All these duplicate fields confuse people when writing JQL queries to filtering issues or configuring Jira automation rules to e.g. adjust fields.

Yes, poorly educated Jira folks in our company are doing that. But hey, weren't these Team-managed projects specifically designed to empower more people to create a project their way.

When I see there is a misleading duplicate like "Labels (Dropdown)", to my knowledge there is no clear way to find in which team-based project these special fields are configured.

All very annoying  

1cc5e9645453 - I'm on Cloud.

Seeing your comment I'm wondering if I understood the case correctly. Do you see a problem to create a duplicate in TMP and use only this duplicate in this TMP? If yes, then I disagree. Do you see a problem to create a duplicate in TMP and use it altogether with one from CMP at the same time? If yes, then I agree.

I see mainly two things to improve:
a) do not allow to use multiple fields with the same names in TMP
b) do not distinguish duplicates in frontend, just use common name and project context which exists at every place

Commenting your cases:
1. "JQL - users can't identify the the field they need, as there are many to choose from in Issues" - Lets have only one name in JQL, no matter how many duplicates are created. If you search in project then you get a filter by a project key by default, so what is the point to use special project-only field name? From the other side if you want to create a global jql/filter then such common name makes this filter maintenance free.
2. Filters/Dashboards: the same as 1.
3. "Sprints - system fields should definitely not be allowed to be duplicate in TMP!" - agree, but only for fields which are always included in issue data and cannot be intentionally removed from issue type list (this is a case I mentioned earlier, where duplicates are used at the same time in the same TMP)
4 "Exports - field contents are blanked out!" - this is a bug, right?
5. "External System Importer - can't write to duplicate fields" - this is a case where duplicates are used at the same time in the same TMP?
6. "Rules - can't update a field if its a duplicate" - every rule (or at least its components which work on issues) is executed in a context of issue from particular project. Why don't we want to use a common name as we already have it narrowed into particular project?
7. "Plus, a lot of teams want to collaborate across projects and that is not possible if TMP users create masses and masses of duplicate fields." - I see this opposite, I would like to ask you for some examples, please, as I don't see a problem here. Having the same name I see things easier to use and maintain. 

I agree that some things need to be improved in Jira frontend, but not in a way the case suggests. Differentiating these fields will cause that every single global jql/filter/automation will needed to be updated for every single new field. Moreover, as far as I remember removing a field will cause whole jql/filter not working without any warning. So imagine you have a filter with N different names and in one TMP a team has changed field name, and you have whole filter in error state.

7c134b43cfa4 - Are on on Jira Cloud or DC? 

In our experience on cloud, even when the project is singular, the users are finding all these things break when there are 2 or more fields with same name & type:

• JQL - users can't identify the the field they need, as there are many to choose from in Issues
• Filters
• Dashboards
• Sprints - system fields should definitely not be allowed to be duplicate in TMP!
• Exports - field contents are blanked out!
• External System Importer - can't write to duplicate fields
• Rules - can't update a field if its a duplicate

Plus, a lot of teams want to collaborate across projects and that is not possible if TMP users create masses and masses of duplicate fields.

Why do we need this (to rename these fields and make these names unique)? If JQL/filter is a project-context search, then it is clear which field we are searching for, or if there is no project restriction then we still iterating issues from projects, so we still have a context for every check. In automation we have similar situation: every one is triggered in context of some project and then it is clear which field we are looking for. The only doubt is to use both company-managed and team-managed fields with the same name at the same time in team-managed project, and I think it could be prohibited.

I see having fields with the same name as an added value. Any automation/filter using such fields is simply universal and maintenance free. Let say we have  a global automation which triggers when some fancy field is changed. Implementing your suggestion we will need to update it every time we add fancyN field

I agree that Jira frontend in many places shows these fields in a way which doesn't allow to recognize their origin, but I'm not sure if it is needed at all! Let say in JQL: why do we need a special name if we can narrow it by project? In automation: why do we need to know exact origin if it is already limited by trigger issue project? For maintenance sake: do not force us to rename these fields

My workaround is to put the project key in parentheses after EVERY custom field. Looks bloody ugly and seems to do a great job of confusing non-admins.. but does the job for me.

We started using Team managed projects when we went to Cloud because it seemed like such a good solution to our thousands of users and hundreds of projects to not have every one of them need to work with the admins to make changes.

That was until a team managed project admin added a field they wanted for their team, and all of the bug tracking filters and automations for our main corporate engineering project broke, causing mass chaos and lost time while the Eng project admins and our entire DevOps team scrambled to append "[Value]" to the end of the existing custom field of the same name to dozens of filters and boards and automations....on release build day....what a mess and waste of time and money it was.

Team managed projects should simply be blocked from creating fields with duplicate names...if they REQUIRE that field then they can make a similar name, or they can work with admins to create the duplicate in a way that doesn't break everything else (can you use contextualized custom fields in Team managed projects?)

We basically cannot use Team managed projects now, and may have to take over ownership of the existing ones to keep this from happening again.

This is an example for large number of fields you get when querying a field.
Perhaps a prefix to identify fields related in Team Managed projects would help. 

e.g. Comments - Tcf[12345]  - T stands for Team Managed Project
-----------------------------
Comment
Comments - cf[12345]
Comments - cf[12356]
Comments - cf[12367]
Comments - cf[12378]
Comments - cf[12389]
Comments - cf[12390]
Comments - cf[12310]
Comments - cf[12322]
Comments - cf[12333]
Comments
-----------------------------

A simple solution here would be to exclude team-managed fields from JQL searches by default, and then have a flag or a JQL function that would enable them. 

e.g. project = "abc" and myCustomField = "Blue" and includeTeamManaged = "true" ORDER BY Created

Since we are designing and using the system based on the assumption that we are creating fields with the same name, we ask that restrictions on fields with the same name not be implemented.

However, it is true that searchability is significantly reduced when there are fields with the same name, so we ask for improvements on the display and search method side.

Who would have thought it?
Multiple things named the same
Might confuse somebody!

[Points out how predictable this problem would be, how many people it impacts, and how long it's been an issue with no fix]

• As much as I would like to, I don't think it's feasible to enforce field name uniqueness for TMP's because they are explicitly designed to work in a vacuum and so what other projects do should be irrelevant.
• Similarly, I don't think it's feasible to show\hide these fields based on context; it would be massively complex trying to determine the specific fields a user could\should see, and it would ultimately not prevent confusion around identical field names if a user SHOULD be able to see them.

I think the only viable solution would be to append the project name in some way to the field in all situations i.e. searching for 'status' might show:

• Status
• Status [Dropdown]
• Status [BizOps] [Dropdown]
• Status  [Marketing][Dropdown]

With...

• "Status" being the system field defined by workflow
• "Status [Dropdown]" being a single select custom field named "Status"
• "Status [BizOps] [Dropdown]" being a single select custom field named "Status" in the "BizOps" project
• Status  [Marketing][Dropdown] being a single select custom field named "Status" in the "Marketing" project

We're already doing this with type, so it makes sense to do the same for fields sourced from team-managed projects.