Configuration via script mode?

Originally asked by Lukas Precht on 18 January 2022 (original question)


Because of our Privacy Policy we have to use a connection between a local and a public instance. In this case, we can´t use the Visual Mode. We are not allowed to set up our local instance to public. But we have to restrict the sync to projects. We don´t want to use the automatic sync via Triggers, too. What are our possibilities to restrict the sync to projects without using the Visual Mode and Triggers. Is there a possibility of Restriction via Script Mode?


Comments:

Daniel Carvajal commented on 19 January 2022

Hi Lukas

With a scripted connection the project which the connection is assigned to is defined in the script, for example:

if(firstSync){
   issue.projectKey   = "KAN" 
   // Set type name from source issue, if not found set a default
   issue.typeName     = nodeHelper.getIssueType(replica.type?.name, issue.projectKey)?.name ?: "Task"
}

In this example the connection will only create tickets to “KAN” project, our advice is to keep separate connections for different projects.

When you sync a ticket you will have the option to select which connection is used to sync that ticket, I believe this might be the option since you don’t want to use triggers, but triggers can also be defined individually on each connection. https://docs.idalko.com/exalate/x/pAHBAg

Hope this is helpful.

Cheers,

Daniel

Anette Huber-Kemmesies commented on 20 January 2022

Hi,

But we only want to connect one project from our local instance to public, e.g. issues of project “A” from our local instance to project “B” to public instance. We don´t want sync issues of our local instance from project “C” to project “B” in public instance.

The example above doesn´t work, because we are still able to sync issues of our local instance from project “C” to project “B” in public instance. How can we exclude other projects from syncing?

Best regards

Anette

Answer by Jorden Van Bogaert on 10 March 2022

Hi Lukas Precht , Anette Huber-Kemmesies

You can use the “Exalate Now” postfunction in the workflow to trigger a sync instead of using the “Triggers”. This makes sure that only admins can configure this and that you define which connection to use.

In Exalate “General Settings” you can also disable the “Show Exalate and Connect actions”, which will remove the button under the “More” menu of the Jira issue.

If you follow that approach, you basically limit it to only the workflows you want.

What we did in our instance is to add a transition to the workflow from status “any” to “itself” (transition from current status to current status) with the Exalate now post function. Here we added a condition to only show when the issue is not yet under sync.

You can also add multiple conditions/validators with scriptrunner/JMWE to prevent the transition from being used in certain scenario’s.

Kind regards
Jorden