Changing a field's settings in a field configuration affects ALL other field configurations

It looks like when i change the "screens" for a field within my XYZ field configuration, it changes for all field configurations including the "Default field configuration" i.e. all field configuration changes look like they are Global changes...what am i doing wrong here

2 answers

1 votes

Screens are not part of a field configuration, they are completely separate things.

A field configuration tells a project/issuetype how to handle fields, in terms of rendering, visibility and mandatory/optional.  These are grouped together in "field configuration schemes" which are then applied to projects.

A screen is a list of fields to be presented to the user when they are doing something with an issue, i.e. Create, edit, view or transition between status.  Create, edit and view screens are controlled by the "issue type screen scheme"

I suspect that you are editing screens thinking that they are linked to the field config.  You are not, there is no link, you are editing shared screens.  If you want to change screens without affecting current ones, you'll need to create new ones and put them into issue type screen schemes

Ignacio Pulgar Community Champion Nov 25, 2016

+1: Very well explained.

Please see my comments on your answer. Unfortunately, I posted them as an "answer" to myself...sad so you would have to go to the web page  - your answer is not applicable to the issue I am having, i have provided some screen capture to show the problem better...

k i understand the difference between screens and fields - i have separate screens as well.

What i am encountering is shown in the two screenshots below. When i change the list of "screens" in one, the list changes in the other one as well, although other elements (required, renderer,...) don't seem to have that problem...as can be seen in screenshots below...

Let me know if that does not clarify the issue I am having.

---------

In Field Configuration A (created for my 3 projects)

SHARED BY 3 PROJECTS

The table below shows all fields configured in JIRA and their properties for ITI Story field configuration.

You can use this page to make fields required, hide/show fields and specify their description. You can also change the screens the field appears on by using the "Screens" link next to each field.

NameScreensActions
Acceptance Criteria REQUIRED[Wiki Style Renderer]

 

Enter UAT or other acceptance criteria that must be met before story can be DONE

 

 

------

And in Field Configuration B (which just happens to be the default one shared by all the other projects)

 

Get help!

View Field Configuration

SHARED BY 14 PROJECTS

The table below shows all fields configured in JIRA and their properties for Default Field Configuration.

You can use this page to make fields required, hide/show fields and specify their description. You can also change the screens the field appears on by using the "Screens" link next to each field.

NameScreensActions
Acceptance Criteria
[Default Text Renderer]

Enter UAT or other acceptance criteria that must be met before story can be DONE

No, you have not understood.

The screens are not related to the field configurations.

They are separate entities.   When you use that link to go to screens, it takes you to the global list of screens.  You're editing shared settings.

You need to consider these two facets separately

Ok - let me see if i got it this time. Taking an example...

For the custom field "Acceptance Criteria" shown in the screen capture, the list of Screens (2nd column) is a shared list - if i alter it in one field configuration, i should expect that all other configurations will show the updated list of Screens in the 2nd column.

continuing...In order that i have the field behave differently (required, show/hide etc.) i just set those attributes within the different field configurations as needed and that works just fine...

However, even if one of the field configurations (lets say the "Default..." one) has a screen where the field may be needed, the screen must be listed in that 2nd column.

Have i got it correct now ?

Thank you for your help.

 

Ok, let's look again at this statement, in two parts:

>For the custom field "Acceptance Criteria" shown in the screen capture, the list of Screens (2nd column) is a shared list

Almost.  I would use the word "global" rather than "shared", but yes, I think we're saying the same thing.

>if i alter it in one field configuration

This is where you are going wrong.  The screens are NOT "in a field configuration".  That link is nothing more than a shortcut to the screens.

Please have another read of the previous answer.

 

Ok i think I am saying the same thing - I should have spelled it out – instead of "If i alter it..." - If I alter the list of screens for that custom field by clicking the adjoining "screens" link in the 3rd column (in any field configuration)..."...etc.

Thanks for your help.

 

And i will tell you why it isn't instantly apparent that this list of screens is a "global".

When you click the "Hide" link in the 3rd column, access to the screens list is also gone...i.e. the "Screens" link is taken away

A "global" link would have stuck around, not be hiding because of a some "local" field condition.

just my POV.

-----

Of course the proper UX would be to put the "Screens" link in the 2nd column itself and visually differentiate it from the screen links themselves...not in the 3rd column with the local options...

thanks for the explanations and your help.

I know the interface is a bit misleading to new admins who haven't quite realised that the screen and field schemes are separate things.   Personally, I'd simply drop the link to "screens" off the field configuration entirely - I can see that it's a potentially handy shortcut, but it has misled many people like it has you.

Suggest an answer

Log in or Join to answer
Community showcase
Teodora [Botron]
Published Thursday in Marketplace Apps

Jira Inferno: The Nine Circles of Jira Administration Hell

If you spend enough time as a Jira admin - whether you are managing a single, mid-sized instance, a large enterprise one or juggling multiple instances at once - you will eventually find yourself in ...

594 views 2 15
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot