Screens and Field configurations many-to-many relationship

[steliosavramidis]

Hello

My understanding is that there is a many-to-many relationship between field configurations and screens meaning that

- A field configuration may be assosiated with many screens

- A screen may be assosisated with many field configurations that define the same field. 

What happens in the second case? Which field configuration decides whether feature A will be, for example, required or not? 

Top give an idea I have a field Enviromnet which is assosiated with both the Bug field configuration and the default screen field configuration. Both Field configurations are assosiated with the Bug Screen. What would happen there? 

[Walter Buggenhout]

Hi @steliosavramidis,

Even stronger: there is no relationship between field configurations and screens. Screens and fields can both be associated with projects, but not with each other.

When you link a field configuration to a project, that will apply to all fields in a project. No matter what issue types you have in there. If you decide to hide a field in your field configuration,  you will never be able to see that field on any issues in your project.

Your screens are linked to the issue types in your project. Screens are a collection of fields, grouped in screen schemes based on the types of operations you want to perform (create / edit / view issues) and linked to issue types via issue type screen schemes. It is possible to use different fields for bugs than for e.g. stories.

Hope this helps.

[steliosavramidis]

Actually it confused me even more. You cannot assosiate the entity of field configurations with screens but you can assosiate fields inside field configurations with screens, so the question still stands: 

You guys have a screen literraly just for that

Listen all I want to do is have an field called Enviroment to show up only for Bug type tickets and be mandatory and right now I am a bit lost. Why is this is so complicated? 

[Walter Buggenhout]

Hi @steliosavramidis,

On that screen, you are linking the Environment field to one or more screens. On a screen, you can create tabs to organise fields in a logical way (visually). I can see from your screenshot that you don't have any screens where you added any tabs, which is why on every screen you will see the field tab as the location where your field will be placed.

If you read the screenshot carefully, you can see it says: "associate the field to the appropriate screens". Field configurations have literally nothing to do with that.

Let me try to just help you with what you are trying to achieve: make sure that the field is just available for bugs and mandatory:

• Make sure that you have created the field: ✓
• Associate the field with the bug screens you use in your project. Check your project settings to find which screens are used for Bugs. This may be between 1 and 3 screens - it depends if you have different screens for the create - edit - view operations. Check under Project settings > screens.
• To make the field required for bugs only, look at the workflow associated with bugs in your project. On the create transition of your workflow, add a fields required validator and have it check your environment field. This will make sure that your users will receive a warning message and cannot create a bug without the field filled out.

Yes, there is a bit of complexity here. But also great flexibility and power to configure this exactly the way you want in relation to your process.