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
