Viewing data from a consistent custom field across projects

Tim Grimshaw April 27, 2020

Forgive me for my newbie-ness... I've done a fair bit of googling and couldn't find the answer, so it maybe that I'm just not seeing it, or maybe I've set things up incorrectly!

Anyway, my question is, we have a number of projects - some next-gen projects, some classic. We've built a feature that uses a field across every project - so we have e.g. Field1 as a custom field created once for the classic projects (which shared automatically across them all) and also a Field1 set up for the next-gen projects individually. 

Everything works great, except for viewing data... so when I want to see a view of x columns, including the Field1 column, I can't find a way of only showing one Field1 column.

I have to have a view that shows customfieldx, customfieldy, customfieldz - which are all Field1 columns from the different projects. So e.g. customfieldx is the Field1 column from the classic projects, and customfieldy is the Field1 column from the first next-gen project... and so on.

It works, but it means that there's a lot of wasted space, because obviously when it displays a row for the first next-gen project, it only has a value in the customfieldy column. 

Hm. Is this making any sense? hehe

In short, is there a way of saying 'there's a custom field called Field1 in all these different projects, show this 1 column with the value from either of those columns across projects'?

I'm almost thinking I need some kind of 'concatenate' function of some kind - where you could say 'Show Field1 column where value(customfieldx)+value(customfieldy)+value(customfieldz)' etc... 

Is this something that other people have come across when trying to tie in a single field that goes across all kinds of projects, or is there a better way to do this that doesn't run into that issue?

Thanks!!

1 answer

1 accepted

0 votes
Answer accepted
John Funk
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 28, 2020

Hi Tim - Welcome to the Atlassian Community!

So if I understand correctly, you have two custom fields with the exact same name? If so, that's going to get you in trouble at some point - maybe now  hahaha.

Is there no reason that you can't slightly change the name of one of the fields? Add a period at the end or something, Just something to differentiate them. 

Tim Grimshaw April 29, 2020

Hi John,

Thanks for your reply! Really appreciate it. Yep I can definitely rename them so they're different, but will that let me do what I'm after? 

We basically have a process that we want to standardise across all our projects, so in a fictitious example we have a field called 'Colour' and we want to be able to fill it out with 'Blue' or 'Green' or 'Orange' etc. We then run automated processes on that field to do different things - like we change the color of the website to Orange if we have more Orange Jiras than Blue etc.

So for our old, classic Jiras, we add the 'Colour' field, and we can then see it across all our old Jiras. For the new next-gen projects, it doesn't have that field, but we still need to record the colour. 

What do people do in this situation? 

If we have e.g. 'Color old' for the classic Jira field, and then 'Color Plant' for the next-gen plant project, and 'Color Bottle' for the next-gen bottle project etc, then we can fill in the color for each Jira, but in feeds / filters / views etc, we would somehow have to pull the data out of 3 different fields, to get the full view. 

E.g. if I wanted to show the blue Jiras, I'd have to have a filter that says 'show me all the Jiras where either color old = blue, or color plant = blue, or color bottle = blue. And then in the view itself, I'd have to have 3 columns listed, and it would only show 'blue' in the column that relates to that project.

Hope that helps - sorry, again I'm not sure if this is something that's a limitation of having classic and next-gen projects or if I've missed a way to do this easily - but I assume everyone must run into this if they're reporting across multiple next-gen projects? 

John Funk
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 29, 2020

Ah, I see what you are saying now about the Next-gen fields. I am trying to get some clarification on that from Atlassian and will let you know. 

Tim Grimshaw April 29, 2020

Awesome - thanks John - again, really appreciated. 

I assume other people must have 'global' fields (similar fields across multiple projects) that they're battling with too, so I can't help feeling I'm maybe missing something simple :) 

John Funk
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
May 1, 2020

Hey Tim - Finally ran across this: https://jira.atlassian.com/browse/JRACLOUD-71712

So you should vote for that and follow. But bottom line for now is that it can't be done. You have to create multiple fields as you have done which leads to all of the other problems. 

But I know that there are certain functions in Jira that if you have two fields that are named exactly the same, it will not show one of them or allow you to use it. I don't remember where that is, but it might be in the workflow stuff somewhere (Conditions and/or Validators). 

Tim Grimshaw May 3, 2020

Ah thanks John!! Good find :) Yeah, fair enough - I'll definitely keep my peepers on that one!! 

Once again, thanks for all your help - much appreciated!

John Funk
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
May 4, 2020

Glad I was able to help. 🙂

Suggest an answer

Log in or Sign up to answer