We are trying to find a way to mark projects that are OpenSource/Upstream so they can easily be identified and be exempt from certain internal policies. The only two ideas we’ve come up with is using categories for projects or coming up with a naming scheme.
The issue with the above ideas is we have a large Jira instance in which different teams have already set their own categories. For existing projects it would be infeasible to find and change every project's name or category because there are so many, and doing so would be disruptive across the company.
Is there another way to approach this that we are missing? Are there applications we should be exploring that allow for multiple categories or setting different project types? Or something that can be done via scriptrunner?
I'm not sure if that really aligns with your need.
What is the nature of the "internal policies" that is driving you to flag certain projects? Do these policies pertain to how the projects are configured in JIRA? What do you need to be able to do with the information about projects that fall into this category you're trying to create?
You're exactly right, Trudy. We require a minimum set of fields (and other configuration) to be used in our Jira projects so we can roll up the right data to programs and portfolios above. Projects designated as "upstream" are exempt from this. We basically want to be sure we're applying the policy in the right places and not disrupting upstream communities needlessly.
To summarize what we're looking for: a means to categorize projects with a small set of possible values that are defined at the system administration level (not changeable by a project admin), in order to enforce certain configuration standards for some categories of projects and not others. We don't want to interfere with the way projects are currently using the existing Category.
So I think what we're looking for is an alternative that functions essentially the same as the existing Category that we can add without affecting the existing Category. @Jay Greguske please correct any details I might have misstated.
Hi Clark, Jay & Diane,
I am wondering if "project properties" could have a positive impact.
Seeing Clark stated it is a server installation I opened the API reference to gather details.
While not documented extensively I feel it could be at least a start for a discussion/evaluation:
To be honest, I have never played with it much but at least I want to cite the reference page:
You can use [project properties] this resource to store a custom data against the project identified by the key or by the id. The user who stores the data is required to have permissions to administer the project.
I understand that adjusting a huge amount of projects will be time-consuming. At least this approach can be scripted using REST API.
Also the requirement from Diane is not met stating that only system administrators might change the configuration. However, this feature in my understanding is not very wide spread - so it could be applicable still.
Please double check if the approach is suitable at all and please do leave a comment if the requirement was understood in a wrong manner.
For JSM June Challenge #2, share how your non-technical teams like HR, legal, marketing, finance, and beyond started using Jira Service Management! Tell us: Did they ask to start using it or...
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