nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Identifying certain project types

Clark Everson

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?

Accepted answers

Trudy P Claspill

I found another post from 2018 where somebody was talking about tracking of projects and the suggestion from @Nic Brough -Adaptavist- was to explore this app:

https://marketplace.atlassian.com/apps/1210816/projectrak-project-tracking-for-jira?hosting=server&tab=overview

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?

Daniel Ebers

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:

https://docs.atlassian.com/software/jira/docs/api/REST/8.13.0/#api/2/project/{projectIdOrKey}/properties

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.

Regards,
Daniel

All comments

Vero Rivas

Hi @Clark Everson

You have valued using the "component" field, which will also allow you to locate them in searches, filters, boards, etc.

Cheers

Trudy P Claspill

I found another post from 2018 where somebody was talking about tracking of projects and the suggestion from @Nic Brough -Adaptavist- was to explore this app:

https://marketplace.atlassian.com/apps/1210816/projectrak-project-tracking-for-jira?hosting=server&tab=overview

I'm not sure if that really aligns with your need.

Clark Everson

@Jay Greguske @[deleted]

Could you add more context? This app may work or maybe heading down the correct direction

Jay Greguske

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.

unknown

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.

Daniel Ebers

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.

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.

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.

Regards,
Daniel

Jay Greguske

Thanks Daniel, that is an interesting observation. I see the APIs are marked experimental, but we'll give this a look to see if it works for our use case.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

server

jira-software

jira-software-server

data-center

enterprise