configuration via script mode?

 
1
0
-1

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?

  1. Daniel Carvajal

    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

  2. Anette Huber-Kemmesies

    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

CommentAdd your comment...

1 answer

  1.  
    1
    0
    -1

    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

      CommentAdd your comment...