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

Next challenges

Recent achievements

Recognition

  • Give kudos
  • My kudos

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage
Highlighted

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
TAGS

Community Events

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

Find an event

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

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you