Stefan Salzl Community Champion

Hi @Girish Kumar Mayigowda and welcome to the community, This feature is valid also for github. I lately struggled with it too. The following link helped me to get it running and the commit needs to be linked to an issue via issue key: https://github.com/marketplace/actions/deployment-action Hope this gives some helpful…

@Monique vdB I did and already got all the information and working through the trello board 🥰🙏🏼💪🏼🥳 Thanks for considering me for that honoring role 🙌🏼😘

As mentioned in my former post I see 2 different use cases (especially from a technical perspective): * when subtask is create within a "done" story --> transition story to backlog * when ?? new story added to epic and status != done --> transition epic to "Backlog" The point is the structure: * Epic* Standard issue*…

Hi @Dann Williams , This needs to be split if you would like to do this for "subtask - story" (which is child-parent) and "story - epic" (which is not the same connection, "kinda" child-parent, but more a linking). Regarding the rule you posted I would suggest: * add a condition right after trigger checking issue type =…

Hi @Henry Yei , For better understanding and analyzing the problem: Could you please provide more date? --> screenshot of your rule and audit log would be great to see what happens. Best Stefan

Hi @aswini.harinath and welcome to the community, the rule could look similar to the following (please add your correct field, maybe smart values need to be converted as I dunno if story points and time can be compared but this should give you a hint on how it could work - assuming I got your requirement right 😊): Best…

Hi @Ananth To get you right: There is already an automation rule in place that does the work correctly (creating issue with summary similar to trigger issue) but you would like to have the ~20 issues before that rule was created be the same? In this case this sounds more like a bulk edit as I cannot figure out how an…

Hi @Patricia Silva and welcome to the community, xray test execution is a jira native issue. Therefore the jira api would be your choice: https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-attachments/#api-rest-api-3-attachment-id-expand-raw-get As seen in the past the term test execution is often…

AAAAAAWESOME!!!! Soooo glad to know it works now! great job man 💪🏼💪🏼

AAAAAWESOME!!!! You nailed it 💪🏼💪🏼 Happy you got that working. Best Stefan

Sure. My curl call looks as follows (keep in mind I´m working in cloud environment): curl -H "Content-Type: text/xml" -X POST \ -H "Authorization: Bearer ${{ $XRAY_TOKEN }}" \ --data @"test-results.xml" https://xray.cloud.getxray.app/api/v2/import/execution/junit?testExecKey=${key} I got aware that your call consits of…

What does your workflow look like? In which status is your issue that you would like to transition? Does the workflow allow a transition from the "current" status to the required status? Is there any validation or screen configured in the workflow for that transition?

seems like a workflow issue: Does the status "Resolved" exist in that special workflow, for within this project and the issue type you would like to transition? In some posts above that shows a screenshot it was closed. In this rule it´s resolved. Please check your workflow and be sure to which status you would like to…

If there is something not working please consider to add more data to analyze. If we do not see what happen (instead of what is expected) we can only make guesses or nothing at all. As we cannot look into your system (as eg. Atlassian Support maybe could) we rely on every information you see in your system (easiest in form…

Thanks for sharing the rule details. As far as I got it right you would like to to close the original issue so to say: * issue A in project A —> cloned to issue B in project B * then close issue A There is a difference between parent epic and original/source issue. If my assumption above is correct your branch is trying to…

Please add further data for analyze (in order to bring the error message into context). Everything that is in context with the automation and the error message would be helpful: * whole automation rule * audit log of the whole rule * eventually triggering/involved issues * workflow Best Stefan

Hi @Junaid Shahzad I‘m afraid the workflow functions are not capeable of checking triggers for different conditions. I was thinking of doing this with jora automation rules. Did you try this way? Best Stefan

If you are working with pullRequests I would suggest to link both of the branches (QA & pre-prod) into the issue. This is just my personal educated guess how it could work: * trigger "PullRequest merged" * check condition of branches with smart value:* {{pullRequest.sourceBranch}} = QA * {{pullRequest.destinationBranch}} =…

How does your branch structure/flow looks like? are your using a starndard flow (like gitFlow, trunkbased, githubFlow)? Is your "production" your baseline (like your main-branch)? or does production gets branched from main? and then dev from production? and where is QA branched away from? Sorry for that load of questions.…

Hi @Junaid Shahzad and welcome to the comunity ;) first question upfront: Did you already integrate your gitlab into jira so that development info can be shown in jira issues? see following links regarding this topic and how to configure: https://docs.gitlab.com/ee/integration/jira/development_panel.html…

Hi @Ananth , for better understanding your problem it would be helpful to describe your use case from a functional perspective, really step-by-step and leaving out the automtion solution itself you have in mind. just explain * how should the system/any issue/workflow behave * when a certain event happens * and this or that…

We are getting closer 🙌🏼 As mentioned before if it‘s sufficient that the issue is closed right after assignee set - hence issue cloned - I would suggest to add a transition action to closed (or the required status) right after the cloning action. Best Stefan

Hi @Thimo König I disucessed with some of my colleagues and did a small research on that topic. I just can come up with 2 things/links describing the mirroring of bitbucket to github. Therefore I guess this can be done. I just don´t have any experience with but thought it might be interesting for to give it a shot: it…

I don´t see any performance issues on your system. It is good to have harmonized projects/workflow as you could associate 1 WF to several projects and don´t have to maintain several WFs that all do the same. On the other way there is obviously a deviation of that special WF. So (from my point of view) it would make sense…

Could please show screenshot of example issues? (where they were "cloned" this way) Might there be already another automation rule in place that does the cloning? Is there a "clone" link to the original issue in the Application Support Project issue? Best Stefan

If the above shown automation rule is run in the project „Application Support Project“ (triggered by the clone-rule that as far as I can interpret another rule in the Helpdesk Project) this rule will close the cloned issue in Application support. It‘s important to specify the event after which the original ticket should be…

Ok. I´m still a bit confused and not getting the point yet as I´m missing some points in your automation rule regarding your description. I see that you already have the transition of the issue to "Resolved" (which I would interprete as your close requirement). Where is your clone action? Which information would you need?…

wow....that‘s really interesting 🙄 Thanks for sharing that valuable input from support here in the community so that also other users faced with this problems can find the solution. And pretty happy you got this working 🙌🏼 Best Stefan

In which way does copying a workflow affects the performance?