Inherited but independent project configurations

[Trey Washmon]

I'm trying to share configurations between two projects without associating them, for example, i want two projects to carry the same configurations for automation, but i also want to be able to edit custom fields independently without making the change on both projects due to both projects being associated.

When i created my last project, i shared settings between another, and instead of just passing the settings it treats it as if they are both the same project.

does anyone have a solution to this?

[Lorenzo Phillips · Accepted solution]

The feedback/recommendations from @Heather Ronnebeck and @Mykenna Cepek for your use case are spot on. When you want similar style configurations, but independence between projects, copying the schemes of the source project and renaming for the target project is the way to go.

Based on your example, you could copy the Field Configuration scheme and on the new project "hide" that field. Or you could copy the Screen of the old project, rename it accordingly, and then remove that field.

With Jira there tends to be multiple solutions to solve problems, but as you drill down into your requirements or use cases one solution will start to stand out more than the others.

Finally, as mentioned by @G subramanyam you can use the copy feature under the global-level Automation rule link. If you don't have access to the global-level of the automation rules, you'll basically have to open multiple tabs/windows to replicate to another project. If you elevate to the global-level you will want to make sure that you change the Scope from All projects to the appropriate option otherwise you'll either 1) impact all projects that may not want the rule or 2) get a bunch of error because all of the projects may not meet the criteria established in the logic.

One suggestion I have is if the old, source project has rules that you think are reusable, I would elevate them to the global-level and set the Scope to Multiple projects. That way, all you have to do is update the Projects list with the new project to take advantage of the rule instead of maintaining multiple copies of the rule at the project-level.

Hope that helps. :)

[G subramanyam]

Thank you @Lorenzo Phillips for that detailed explanation and insights. I'm liking this question and the responses.

[Heather Ronnebeck · Accepted solution]

The avenue that I take when creating new projects that I want to have the same or similar schemes and configurations between them is copying the configurations/schemes and other items I want to share, and rename them with the new project name. 

The reason I do this is to keep the projects partitioned from each other so making a change in one doesn't impact the other project. 

For example, I make a copy of a workflow that I want and rename it to the new project's workflow. I then apply that new workflow to the new project. Then I rinse and repeat for everything from notification settings, permissions schemes, screens, field configurations, workflows. Basically the whole nine yards. To the end-users, it looks like a copy of the original project, but to the admin, it is entirely separate from the original project and changes to one project won't impact the other. 

[Mykenna Cepek · Accepted solution]

When creating a new project in Jira, the "Share settings with an existing project" option can be confusing.

Checking that box allows most (not all) of the configuration for an existing project to be reused for the new project. It can save an admin quite a bit of time.

But often the new project is NOT an exact config copy of another project. That's when things get tricky.

However, it really is a black-or-white issue for any given configuration (e.g. Workflow Scheme) -- EITHER the new project and the old project share that scheme, OR they use separate schemes.

Since projects have 6-7 schemes associated with them, there is a lot to manage. The new project might share 4 schemes with other projects, but need 2-3 custom schemes. That's part of the "fun" of being a Jira admin.

@Trey Washmon, I'm not clear enough about your exact situation and concern to offer a specific recommendation (automation is configured separately). But hopefully this overview provides a language for clarifying the context.

[Trey Washmon]

Hey Mykenna, thanks for the response!

Ok so, to clarify, i basically want to separate my project from associating with another project so that if for example i have a drop down categories custom field for a department in project 1, i can remove it from project 2 without deleting it from project 1, but i want to keep the settings for things like automation and my SLA's.

[Mykenna Cepek]

It sounds like you're talking about JSM rather than Jira proper, but the concepts should transfer. I'm writing from a Jira Cloud perspective.

Let's look at your example of a Department custom field that shows in one project but not another. That impacts Fields and Screens (configuration and schemes). So as @Heather Ronnebeck mentions below, you can COPY those configuration elements in order to have separate ones for each project. For example:

• copy "ABC Field Configuration" to "XYZ Field Configuration"
• copy "ABC Screen Scheme" to "XYZ Screen Scheme"

But you might keep the "Common Workflow Scheme" that most of your projects work, as an example.

Automation is configured rule-by-rule. I don't believe the "Share settings" checkbox when creating a project affects automation configuration. So you'd add new projects to the automation config as needed.

[G subramanyam · Accepted solution]

Hi @Trey Washmon welcome to the Atlassian community.

I would like to pitch in to this post to share my 2 lines. However, I will be in the waitlist to read the answers from other users.

In the global administration>> More options section>> you will find the following options that applies and between cloud sites.

                                         

[Trey Washmon]

These are all fantastic solutions, its really tough trying to pick the accepted answer at this point.

I may have gotten the answer that i needed, but ill wait to see if anyone has any other solutions before i go ahead and choose an answer so that maybe another user with a similar problem has a different solution if the one i chose wont work for them.

[G subramanyam]

Hi @Trey Washmon my suggestion here. Each of the answers go hand-in-hand from starting till end. So, you may accept all the answers!  :)

[Trey Washmon]

Oh! i did not know that, thats perfect!

thank you!