Jira automation: access {{issue}} variable during issue creation - jira

Is there a way to access {{issue}} variable inside a rule that creates an issue itself?
I create an automation rule that:
is triggered by incoming webhook;
creates new issue;
sends web request with some data of newly created issue to another external system.
The problem is that when it comes to the last step, {{issue}} variable is not initialized with data of newly created issue, it's empty. And I need to know at least the key of newly created issue at this moment.
Is there a way to implement this in the creation rule, or I need to create additional automation triggered by creation of new issue instead?
I'd like to keep everything in a single rule if possible.

Answering myself. I have solved this by creating another automation rule triggered by creation of a ticket by 1st rule. Later, however, I have found an information that an issue should be accessible in creation rule as {{createdIssue}} - did not check that though.

Related

Passing variables to Camunda subprocess

I'm trying to model a document workflow using Camunda 7.12. One of the requirements is that the user can define a due date for the whole process, and the system must send a remainder a couple of days before that deadline.
I was suggested to define a subprocess with a timer event that triggers when the date selected by the user in the start form is reached.
So, I defined the following subprocess in the model:
The timer event has the following properties:
The due_date variable is entered by the user in a form when the he starts the process, but I don't know how I can pass it (or if it's even possible) to the remainder subprocess.
Any ideas? Or alternatives on how it could be done?
Thanks in advance,
I found a solution that doesn't involve big changes in the model. Simply, I set the process start event as Asynchronous Before. Now, the timer start event can get the due date value and launch the remainder task as expected.
Cheers,
A related issue was fixed in
https://jira.camunda.com/browse/CAM-9303
and the related unit test
(https://github.com/camunda/camunda-bpm-platform/blob/33601f3026341882afae321611dfe4e8dfd31d2c/engine/src/test/java/org/camunda/bpm/engine/test/bpmn/event/timer/StartTimerEventTest.java#L1351-L1446)
passes on camunda 7.12 and also on the #SpringBootTest I created.
However, I saw the same issue when testing manually via tasklist using this process:
https://cawemo.com/share/6bf324bb-4002-490c-8739-7ca94803acc0
Tasklist uses an API which differs from the call used in the tests.
Possible workarounds I see:
a) Wrap API used in test runtimeService().createProcessInstanceByKey(...) with own REST service and start via this endpoint.
b) Change process model and move process into embedded sub process, then attach intermediated timer event to it. This creates the variable before the event is registered. Example here:
https://cawemo.com/share/870694cf-b704-42c2-b0d7-a2637406d356
A new JIRA ticket for this issue in the context of form variables has beenc reated here: https://jira.camunda.com/browse/CAM-11357

I have created a rule to automatically create a Child Task but it is not working

I am using Azure DevOps WIT One Click Extension. I am trying to create a Rule to generate multiple Work Items (Child Tasks) when an specific Work Item gets saved or assigned to an individual.
I have tried over and over and the rule does appear for me to manually executed but it is not working to automatically generate the Tasks.
I have no code... I am not a Programmer or Developer. I am a user trying to use the tool
I expect the rule to work and automatically create the Child tasks when the Request Item (Parent) is saved or assigned to someone.
I'm afraid the trigger way you want does not support by this extension now.
generate multiple Work Items (Child Tasks) when an specific Work Item
gets saved or assigned to an individual
For this rule you would like -- save a specific work item and assigned to an individual are belong to trigger way -- as I understand, what you want is when a work item saved and be assigned to someone, it will trigger the action generate multiple child tasks.
So, in this rule, save a work item or assign it to someone is trigger way. The action is generate multiple child tasks. But, unfortunately, these trigger ways does not be support by this extension. It just support New work item load and Field changed now.
That's why it does not working automatically. Because the trigger way you configured not supported.
The rules you can create which also supported by this extension, is open a workitem or change one field will link a child task.
In addition, I also check the rules which Azure Devops support. The trigger way you want are also does not supported.

JIRA- How to immigrate data from an issue to another?

Currently I am working on a Jira project and in that project I have built a workflow. The workflow runs with a single issue and runs successfully.
This workflow mainly consists of 2 parts. In the 1st part, the authorizations are set and approved. In the 2nd part some assignments are being conducted according to the authorizations that have been set in the first part.
This workflow works well but I have been asked to implement this project with 2 different workflows which will be run by 2 different issues.
So my question is, how can I migrate data from the first issue to the second issue? Somehow I need to transfer the authorization info to the second issue so that the second workflow will be able to run.
Thanks a lot.
Once the authorization is complete you could change the issue type to a type which uses the second workflow. If you want to retain the authorization record, you could clone the first issue and then change the issue type of the clone.
A late respond: I achieved this by using the sub-task mechanism. I also used post-functions in the workflow which made me able to get the authorization data from the first issue.

How to Change/update grails view (gsp) from service class

I have a Grails Application, which has a self implemented chat system. Now I am trying to refresh the sit ( or the box containing the messages in particular), as soon as a new Message arrived. So far I figured out three methods:
Poll from DB every second (every incoming message is saved to DB), which would be the easiest, but create a lot of unneccessary DB usage
Update the view from within the Messagelistener. I dunno how to do this though, what I am looking for is kind of the remoteFunction-tag as a function to call from within a service.
Update the view from domain class via beforeInsert-event. This is my least favourite option, plus I don't know how to do it for the same reasons as option 2.
If someone has a better option or a way to realize one of mine I would be very thankful :)
try http://vertx.io/ out. It's easy to setup and should do just fine for asynch-messaging

Importing custom data into Jira issue

I am looking for a simple way to get data displayed in an issue as just plain text. Basically, I want to be able to type in a lookup id in the issue creation and then once the issue is created, it would call one of our web services to retrieve data connected with that ID.
This wouldn't be coming from another issue tracker, but rather straight from one of my databases.
What would be the easiest way of accomplishing this? I would like the workflow to be: Enter id #, hit save, see the data with that ID displayed in the ticket (Doesn't need to be editable, just displayed in the ticket view).
The easiest way is to create a workflow function that is triggered at Create transition to do the job. There your code can query information from the database and replicate them into JIRA standard and custom fields of the issue itself.
Then you can prevent edition of replicated fields by tuning Edit screen for your issues.
You can also use your function to update field content from time to time, either at transition or in a trigger.
An option is to create some read-only custom fields than query each piece information from the database. It will prevent data replication but it will be probably slow and it does not apply to default fields.

Resources