Stefan Salzl Community Champion

Hi @Syed Majid Hassan -Exalate- First of all: I love exalate and it´s functionality. It´s really great to be able to sync over several tools. and: This is mainly the Atlassian Community to investigate into people´s problems within atlassian and try to do suggestions to find a solution for them from where they are right…

Hi @shashi budidha and welcome to the community! The described behaviour is mainly a feature of the workflow as it can "wait" for the action to be done. It´s also best practice to solve workflow related steps within the workflow (validation, screens, post-functions, etc...) rather than with automation. A4J can automate…

Is the clone action handled in another rule? is there a further question?

Hi @Robert L. Nowitzke , Without knowing your rule details I would say: yes. As you are obviously handling the original ticket (as you clone it) you could add another action to yout automation rule after the clone that transition to the required status (eg. „Closed“). If this needs further please send a screenshot of you…

ok. I see :) not everybody in hear is a developer and knows about the differences. In this case my explanation was unnecessary. The point is that the part in the paranthesis checks 2 different „entities“: once presence of subtasks vs. status of subtasks (even further entities that depend on each other which even consits of…

Those are basically contrary concept: AND - all of the conditions met and resulting in one action OR - at least one of the condition matches and has a dedicated result IF/ELSE - either one or the other condition matches and a dedicated result regarding which of the conditions matched

Hi @Itay Stainfeld If your question is answered please consider to click "Accept" in order to mark this case as solved. Best Stefan

Hi @Julien Goudeaux and welcome to the community, Your rule shows 2 branches within the same "decision" path. The 2nd branch could never be reached as the rule will break as soon as the condition of the first branch don´t match. That´s what an if-else-clause is for: * if* (in your case branch 1) * 1st condition matches *…

It´s my pleasure to be part of that journey to your approches. That looks really great 👌 One more hint: If you don´t want to have 5 different automation rules you could try solve this with a smart value within the clone action that will automatically take the value of the field to know where to clone the issue (see…

AWESOME!!! happy you could make it work 💪 If your issue is solved please consider to click "Accept" next to the answer so that this case gets marked solved. Best Stefan

Hi @Sanjay Mukherjee From my point of view I can just go with @Bill Sheboy furthermore: just had a discussion on that question some weeks ago. Unfortunately I was not able to find a solution on that after trying out several approaches. Best Stefan

mkay...I´m not sure if I got the requirement right so let´s take one step back: entry point is * a custom field is filled with a user name* is that field a user picker? * are ALL users of the jira instance available in that field? * then there needs to be a verification in which project the user from step 1 is part of* can…

The screenshot shows the testcase which is let‘s say the base of a test run. A test run is an entity (an instance of your testcase) generated within your test execution. So to say: The functionality you are trying to run could only update the testrun but not the testcase issue. I know lots of different entities in that…

@Itay Stainfeld Could you please provide a screenshot of the whole item you‘d like to update? Bes Stefan

Hi @Itay Stainfeld and welcome to the community, one question up front: the screenshot looks like from a jira issue (as there is a resoltion field). Maybe I‘m wrong but I‘m not used to a resolution field in a test run. Are you trying to update a field in the test execution or in the test run? Best Stefan

Hi @jtth if there were to be more than ten total collaborators If this number is exeeded you´re running out of the free plan. Commonly Jira is set up for an organization. Within that organization several (so called) sites can be created (the free plan has a limit of 1 site). If those projects are from different…

I would not say I completely confirm your understanding. Although the concept of creating a Test Set AND a Test Execution is alien to me (isn't a Test Execution effectively a Test Set?) this eg. is a clear no if you read carefully through my post. A test set is a collection of test cases. There is no possibility to to…

@Kushagra Gupta sorry I was answering from my iphone and clicked the wrong text field 🙈 my last answer should haven gone here 🙈 sorry for the confusion

That‘s really weird. Can‘t reproduce this? Did you try creating new branches and PRs for test? Ome other thing (even if it sounds like common answer) would be to try to recreate the rule. Otherwise I can‘t detect anything that would cause the problem. If it still ovcurs I would suggest to reach out to atlassian support.…

Hi @alejandro yudis amaya Bonilla I had the same requirement some time ago and found jq to filter json response. Please see the following link: https://stackoverflow.com/questions/62595453/filtering-from-json-output-from-curl-using-jq Hope this helps. Best Stefan

Hi @David Amar and welcome to the Atlassian Community ;) What exactly would be your requirement? As I assume you already have the GitHub-Jira-Integration. Or what does "pull the Jira ticket" mean? If a repository is connected via Github-Jira-Integration and git-entities are done with issue key (eg. commits, branch name)…

Hi @ChrisK It seems a bit complex in the beginning. I´ll try to give a short overview as far as possible: first of all: all xray specific issues are native jira issues and can therefore undergo eg. a workflow and displayed in board Testcase as mentioned before it is a native issue therefore (commonly) created in backlog.…

Hi @Vanessa once again ;) I would suggest to start with a „Field value change“ (guess that‘s the name of it) trigger. You could then add any condition (eg. if only should run for special issue type). Then add a clone issue action. As far as I know int can be configured directly in the action to clone in a different…

AWESOME!!! great to hear you´ve been successful 🙌🙌🙌 Happy testing ;)

That´s the JSON I used in "clone issue" action for subtasks: { "update": { "labels": [ { "add": "cloned" } ], "issuelinks": [ { "add": { "type": { "name": "Cloners" }, "outwardIssue": { "key": "{{issue.key}}" } } } ] }, "fields": { "parent": { "key": "{{createdissue.key}}" } } } In case your rule is exactly configured as…

Sure. That´s the correct behaviour. The "parent" option in the issue´s json will stay the same as the system cannot know by itself where to link the issue. By cloning it copies original issue´s setting (expect they were changed by the automation as made in the suggested approach): again: if you´d like to go for a solution…

😵😵 that looks really weird. Unfortunately I´m running out of ideas :(

Hi @UI91 , could you try this approach? Best Stefan

Hi @Ryan Gill Did the suggested approach work? Best Stefan

It´s perfectly described in the documentation. See the following Link: https://support.atlassian.com/atlassian-account/docs/manage-api-tokens-for-your-atlassian-account/ Best Stefan