Ideas on how to deal with Team managed custom fields breaking existing filters

[jeremyn]

Hi All,

So hopefully this question makes sense, sorry it will be long.

We have started using team managed projects in Jira Cloud for some projects since it takes some burden off our site admins as the team managed project admins can handle issue config, fields, workflows etc. themselves when the project/team is smaller. 

Then this week we had something bad happen, one of the team managed project admins created two custom fields (as he is allowed to do as a team managed project admin), who's names (but not types) matched existing fields (which happen to be used to drive our bug triaging process in our main engineering project).

Then the next morning all heck broke lose as leaders discovered their bug dashboards broken.

My DevOps team quickly discovered that the existing filters were using say "foo != triaged" and now needed to say "foo[dropdown] != triaged"...which means we have dozens of broken filters (if not more).

So, how have you all handled this situation?

1) There appears to be no separation of custom fields between team and company projects, despite indications otherwise in the documentation that team managed fields are their own, IIRC 
2) It is not easy to tell everyone to switch their filters to field IDs since they are non-obvious and a PITA to go find (and we probably have 500+ filters in our jira instance, between normal and scriptrunner ones)
3) It kinda makes Team managed projects worthless if I can't let a smaller team have a bit of freedom, as advertised, to do as they want without risking them breaking a project that is used by many, many hundreds of devs constantly.

[Eric J Trumbull · Accepted solution]

We are encountering similar problems with the crossover between Global Custom fields and Team Managed Custom fields. It has caused problems with queries, reporting, and Automation. 

Our very rough idea right now requires Team Managed project admins to append a standard character of some sort to the end of all custom fields created in Team Managed projects. 

However, we don't love this and it feels like Team Managed projects shouldn't be able to affect things outside of the project. (I also understand that it is in part the cost of being able to report on and build automation that interact with TM fields from a global level)

We are eager to hear other ideas as well!

[Bill Sheboy]

Hi @jeremyn and @Eric J Trumbull (welcome to the Atlassian community!)

Here is an open defect for that symptom of field collisions which you may watch / vote for to see progress:

https://jira.atlassian.com/browse/JRACLOUD-79845

The work-arounds noted in that defect are as you noted: delete or rename the fields.

Kind regards,
Bill

[Eric J Trumbull]

Good to know. Thanks, Bill!

[jeremyn]

Thanks Eric and Bill,

Unfortunately for us, with thousands of users and hundreds of projects, it is hard to leverage Team managed projects if they can interfere at all with company managed ones. To us the whole appeal of the team managed projects was to allow the team to be autonomous and not have to deal with our DevOps team every time they wanted to make a change. 

We just got past having dozens of jira admins when we were on server because everyone "just needed to..." and it was chaos. When I took over our company DevOps we cleaned house on a lot of that stuff and problems have dramatically reduced, but lead times for changes has gone up a lot (since I don't have as many admins). These seemed like such a good solution.

Were already deploying the recommendation (but in our case "You can't make custom fields until you talk to DevOps first")...but also we are just not going to use Team managed projects for the near future as its too risky.