Team system field vs. Team custom field

[Lori Milam]

With the introduction of the Team (team picker field), we are finding some problems with it that we're hoping someone else has come up with a solution.

Background: We created a Team custom field 3 or 4 years ago. It is a drop down list which we control with contexts and is maintained by the Jira admins. Our "teams" contain a list of actual team names, not the "team" from the Teams menu option. We are now up to 203 projects that utilize this field. Now that there is a built-in Team field, we have duplicate fields when trying to add the Team field (ours) to a screen. There is no way to tell when on a screen config which Team field to select from the dropdown.

Moreover, the screens that did not have our Team field on them now have the team picker Team field showing up on them causing confusion with our customers. Switching to the team picker is not an option here. Changing 203 projects to use the new field would break so many things (filters, dashboards, reports, automations, etc.). I tried renaming our team field in the sandbox and that broke a bunch of stuff as well.

Has anyone else come across this or have any suggestions for us to like turn off the use of this new field? Or do we just have to continue to deal with this.

[Stephen_Lugton · Accepted solution]

Hi @Lori Milam 

You can just remove the Team field from all screens in custom fields: (Settings -> Issues -> Custom fields)

Select the screens as highlighted:

Then add or remove associated screens:

Then deselect all screens (click on the highlighted box once to select all screens then clear it to de-select them followed by update at the bottom of the list):

[Stephen_Lugton]

When you add new projects you may have to repeat this process for those projects

[Lori Milam]

Thank you @Stephen_Lugton I was hoping there was a way to just disable the use of the new Team field altogether. But I guess that's not possible. So instead of using the screen config within the project to add/remove this field I will just have to inform our admin team to go through it the other way.

[Stephen_Lugton]

@Lori Milam the Teams field is part of Jira and as such is a locked field available to all projects, and I couldn't find a simple way to disable it. 

You could just go through and configure the screens / issues in each project and just remove the field from that screen / issue, but the method I've outlined speeds that up

[Lori Milam]

Yeah, that's not going to work. We've got hundreds and hundreds of screens. I'll just stick with the first way. Thanks.

[Darryl Lee]

@Lori Milam - what is the other way you found to "disable" the new Team field?

[Lori Milam]

@Darryl Lee I have no way of disabling the new field. We are continuing to use our existing custom field. The new field automatically gets added to every new project so we just go and remove it after project creation. And if the project needs a team field we add ours. It's not pretty, but the new field does not work for us so it's yet another step we have to go through because Atlassian makes assumptions that in my opinion they shouldn't be making.

[Darryl Lee]

Hi thanks for getting back to me @Lori Milam !

So you are creating new Screen Schemes for every new project, as opposed to using Shared Screen Schemes (resulting in hundreds of screens)?

Uhm... That's a lot of work. :-/

It's why many Jira admins rely on shared configurations for Screens, Workflows, Issue Types, etc.

Here's a great article on the topic:

• Configurations overview: Understanding Jira schemes 

And unfortunately with all of their fancy project templates, etc. Atlassian is really driving users to create new schemes for every new project, "hiding" the option to share project settings behind a checkbox after going through and choosing a template:

• Create a project that shares its configuration with another project 

[Lori Milam]

Thanks Darryl. For the most part yes, most of our projects have their own schemes. We have over 300+ projects and probably 98% of them were created prior to my taking on this role. They are created with API collections so we don't use any of the Atlassian templates. Yeah it's a lot work, but I've got no choice now but to push forward.

[Darryl Lee]

Heh, yes, Jira admins often "inherit" messes.

That's interesting that you're using the API to create projects. So are these scripts, or some kind of in-house system? Are schemes truly unique to each project?

If unique schemes are not a requirement, then there could at least be a path forward for new projects to use shared schemes to limit any further pain. 

Just a thought.

[Lori Milam]

Yes, a collection of scripts was written which we run through postman to create the initial project. This is only for Kanban, Scrum, and Triage projects. The schemes aren't truly unique, they are just named uniquely. This might be to allow for special changes once the project gets created. Just a guess.

Updating things to share may be something that I will address sometime in the future when I have a chance to get out from the pile of work I'm buried under. Thanks for the input.

[Darryl Lee]

Oh wow - never thought of using Postman as a platform for that. Super-interesting!

Thanks for providing more context, and good luck!

[Lori Milam]

Thanks Darryl.