nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Configuring fields in project, does have impact on other projects.

jeroen.wilmes

When I'm in a screen for an issue in project "Y" and I select the configure wheel for changing the fields for that particular project, it does effect other projects. Despite all the descriptions in Jira and on the screen.

How I assume that it should work:

If fields are made available in a screen configuration, I should be able to decide per project is I want to add it to the screen of a particular project, only effecting that particular project regardless that the screen is used by other projects.

If my understanding is OK than there is a bug in Jira as repeatedly (but not always) I get the message when adding a field to a screen in one project, that the screen of other projects also get changed.

Am I correct in my understanding?

Accepted answers

Jack Brickey

If the screen scheme is used in other projects then changes to the scheme will impact all projects using that scheme.

Marc -Devoteam-

Hi @jeroen_wilmes

Screens is where you determine what fields are on a certain screen. In a screen scheme you can decide if you want to have different screens for create, edit or view actions.

The issue type screen scheme is used to define which screen scheme is used per issue type on a project.

So making changes to a screen impacts all issues in any project where the screen is used in a screen scheme and and issue type screen scheme on that project.

What you can do on company managed projects is to change the layout, here you would be able to hide fields in the view. This won't impact other projects and the screen.

See, configure-issue-layout

jeroen.wilmes

Giving a example how it works for us.

I have 50 projects and we want some degree of standardization and leave as much as possible space for projectlead to configure their own screens.

Jira seems to support that. I can define the same issue type screen schemes, screen schemes and schemes for all projects

For some projects some fields are not relevant and the projectlead can decide to hide that field.

If a field is hide by let say 10 projects and one of these projects decide that later on in the project the field becomes relevant he wants to add it. At that time he is forced to add it also for the other 9 projects that had hidden that field.

There is only one way to deal with this add the field again for all projects and delete again for the one's that had hide them already.

This brings a lot of work and frustration. Bringing back a field to a screen in a project may not have impact on other projects.

jeroen.wilmes

An example on how it works for us.

We have more than 100 projects. For 50 of them we want to have so level of uniformity. For these 50 projects we created one issuetype screen scheme, screen scheme, screen and field configuration scheme.

Some fields are less relevant for some of the projects and we project leads can remove them for their own project. So far so good.

But as soon as one project leads decide to bring the field back again, then this is only possible by bringing it back in for ALL the projects that had removed it. This is NOT logic at all! What a project lead can remove, he must can bring back without bothering all other projects.

This is also not a reason to create all different schemes as this leads to maintain all schemes is we want to make a change.

All comments

Jack Brickey

If the screen scheme is used in other projects then changes to the scheme will impact all projects using that scheme.

Marc -Devoteam-

Hi @jeroen_wilmes

Screens is where you determine what fields are on a certain screen. In a screen scheme you can decide if you want to have different screens for create, edit or view actions.

The issue type screen scheme is used to define which screen scheme is used per issue type on a project.

So making changes to a screen impacts all issues in any project where the screen is used in a screen scheme and and issue type screen scheme on that project.

What you can do on company managed projects is to change the layout, here you would be able to hide fields in the view. This won't impact other projects and the screen.

See, configure-issue-layout

jeroen.wilmes

Hi Marc,

I follow and recognize all your points except for the last alinea.

Yes it should work that way but it does not.

If I want to change the lay-out I should be able to add fields to the screen that are available for that issue type and the specific operation (create, edit, view) in the issuetype screen scheme. When I do that for some fields it goes correct and the field appears on the screen for only that specific company managed project.

For other fields I get a pop-up screen telling me that I'm going to add it to the same screens of the other projects that have the same issue type screen scheme (or screen scheme).

This is not expected behaviour and that is also what the text in the Jira screen is telling me.

Screenshot 2024-11-12 at 16.59.36.png it says:

....in this project....

add more fields for this screen, go to...

and screens are not defined per project as you explained.

jeroen.wilmes

Yes, I understand and that is indeed what is desired behaviour, but it works also the other way around if I select a field to be shown on my specific project, it appears on all projects that use that screen, and that is unwanted behaviour

Marc -Devoteam-

Hi @jeroen_wilmes

See the link I provided for Layout, this has no relation with screen schemes and the options create, edit and view

The behaviour is as expected, I jut think you are thinking that it should behave differently.

The layout is to removed or add fields that are on the defined screens in the layout of the issue.

The options in a screen scheme to define different screens for the actions, create, edit and view have no relation to this.

It could be that fields are set to hidden in Field Configurations, if you use the same screen on a project, where the field configuration defines the field to be hidden, this will impact on the change you are making.

Then that project should use different screens.

jeroen.wilmes

Giving a example how it works for us.

I have 50 projects and we want some degree of standardization and leave as much as possible space for projectlead to configure their own screens.

Jira seems to support that. I can define the same issue type screen schemes, screen schemes and schemes for all projects

For some projects some fields are not relevant and the projectlead can decide to hide that field.

There is only one way to deal with this add the field again for all projects and delete again for the one's that had hide them already.

This brings a lot of work and frustration. Bringing back a field to a screen in a project may not have impact on other projects.

Marc -Devoteam-

Create a new field configuration for that project and that issue type,

Then there is no need to change any screen.

Or If a field is on screen, but not relevant for a project, adjust the custom field context or add an extra context.

jeroen.wilmes

An example on how it works for us.

Some fields are less relevant for some of the projects and we project leads can remove them for their own project. So far so good.

This is also not a reason to create all different schemes as this leads to maintain all schemes is we want to make a change.

jeroen.wilmes

An example of how it works for us:

We have more than 100 projects. 50 of them we want to uniform to some extend.

We created for these project one field configuration scheme, screen, screen scheme and issuetype screen scheme.

Some fields on the defined screens are less relevant for some of the projects. Projectleads can indeed remove them per individual project. So far so good!

However if the projectlead later on decides to bring a field back again, then that is only possible by bringing it back to the other projects that removed the field as well, and then per project remove it again.

This is not how it should work and this is also not a reason to define different screens (as that brings a lot of extra work to keep projects uniform)

A field removed from a screen of an individual project, must be possible to bring back without impacting other projects.

Marc -Devoteam-

Hi @jeroen_wilmes

As I mentioned, then use custom field contexts.

I hide a field on 2 project using the same issue type screen config and then added a field on 1 project and its only back on that project, not on the other one.

Otherwise contact Atlassian Support on the issue.

jeroen.wilmes

Hi marc, I do see your point. That is one way of dealing with it. For now we move the fields to the section "hide when empty" , than at least the user don't see the fields as they are not used.

But to me this are both work arounds for a design flaw in Jira, and I will raise a ticket for that.

A field removed from a screen of an individual project, must be possible to bring back to the screen of that project without impacting other projects.

Removing it on a projectbases and bringing it back on screen scheme level is not consistent.

jeroen.wilmes

There are 2 way to deal with this one is described by Marc in this issue. The other way is to move the fields to the section "hide when empty" , than at least the user don't see the fields as they are not used.

But to me this are both work arounds for a design flaw in Jira, and I will raise a ticket for that.

A field removed from a screen of an individual project, must be possible to bring back to the screen of that project without impacting other projects.

Removing it on a projectbases and bringing it back on screen scheme level is not consistent.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud