Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,456,634
Community Members
 
Community Events
176
Community Groups

Best practices for limiting the visibility of custom fields

Hello,

I am administrating a medium-sized Jira Software Server with around 200 projects, 1500 users and a little over 200K issues.

I am often facing requests from project admins to modify the visibility of certain custom field for their project or group of projects they work on.

For example the "Story Points" field - some managers wanted it only for Story issue type, others wanted it for primary issue types (Story, Bug, Feature, Task), third group wanted it for sub-task issue types too, fourth group wanted it for mix of the previous groups,...,you see where I am going.

I know several ways to handle this in Jira

  • Configure the field to be applicable for all issue types and projects and then limit its visibility in certain projects by removing it from screens. My problem with this approach is the explosion of screens, screen schemes and issue type screen schemes. For example a project manager wants Story Points to only be shown on Stories and nothing else - I have to create issue type screen scheme for this project, specifiying one set of screens for stories, another for other issue types. Now since I have two screen schemes I need to create 6 screens to associate to the 3 operations (View, Create, Edit) in each screen scheme. Next week that manager will want the Story Points to appear on Bug too, but remove some other field for bugs - more screen schemes + more screens
  • Field configurations - I can hide the field in certain Field Configurations, but this approach suffers from the same weakness of the screens approach - over time the number of Field Configurations will grow and grow
  • Using Custom Field Configuration Context - that's the approach I used. I did not have explosion of screens and field configs, but now I have 4 configuration contexts for Story Points field. Each of these context is applicable to a sub-set of the projects and sub-set of the available issue types. There are 2 more problems
    • New projects, that are created with shared configuration with existing project are not automatically added to the custom field configuration context
    • Removing configuration contexts is tricky and changing the applicable context for one project is even trickier.

 

How do you handle such problems?

How do you balance between performance ('cause the number of screens defined in the system is affecting performance of Jira) and maintainability?

Thanks a lot for your input

0 comments

Comment

Log in or Sign up to comment