Using YouTrack's own REST API from within a Workflow

Hi there,

As we are porting our business logic from Jira to YouTrack, we've come to realise, that Workflow APIs are rather limited as compared to YouTrack's own REST APIs. For example, current user is unable to find out its own ID from within a Workflow, whereas it is possible outside the workflow using REST API (see /users/me).

Which brings us to the following question: in Jira it is possible to call its REST APIs with the privileges of the user executing the workflow via ScriptRunner - it automatically imports Unirest within the scope of the script and all requests made with Unirest are "magically" authenticated as the user executing the workflow. This doesn't seem to be the case with YouTrack's http module. Of course, we could create a token an use this token in the workflow for authorisation as a workaround, but this means that REST API calls will be executed with a different user than the workflow, which doesn't help in the situation described above.

Is there a way out here?

All the best,

Yury

22 comments
Comment actions Permalink

Hi Yury,

Currently, the only way to invoke REST API from workflow is to use an auth token. Could you please elaborate on what is it exactly that you're missing in the YouTrack Workflow API?

Regards,

  Alexander

0
Comment actions Permalink

Hi Alexander,

Thanks for the reply - see the first paragraph in my post for a specific example - an API call can return the ID of the User, but it is impossible to read in from the Workflow entity - only login is accessible.

All the best,

Yury

0
Comment actions Permalink

My question was more about your initial intention, namely about the reason for you to try to retrieve this ID. I suspect you then want to post it to some external system, or something else which I don't completely have understanding of, this is why I'm asking.

0
Comment actions Permalink

Hey Alexander,

Sorry, I have misunderstood your question! Yes, you are correct - my original intention is to pass object IDs (in this case current user ID) to an external system, which can then communicate with YouTrack using the public REST API. If I don't have the IDs, then I have to pass things like logins, and then do superfluous API calls to filter users by login to find the IDs again on the other side.

If you want to know what external system it is in this particular case, I can also elaborate on that. We need a system for our helpdesk agents that would allow them to send emails with attachments to arbitrary recipients (not necessarily ticket reporter or request participant) - all emails sent within the context of the request have to be logged in the request as comments from corresponding agents.

Unfortunately, YouTrack currently does not support widgets in the issue view, only on the dashboard. It also doesn't support user interfaces for actions. So we have built such a system outside of YouTrack. The agent runs the "Email this issue" action in YouTrack and the action hovers a link to the external app with current user login and issue ID. The agent clicks the link to open the app, does his job, and the app posts comments back to YouTrack via REST API in the name of the agent.

All the best,

Yury

0
Comment actions Permalink

Yury,

Thank you for the detailed explanation.

First of all, let me assure that the features you mention -- issue view extensibility and help desk support -- are on our road map, can not give you any ETA though.

Exposing the user id to workflow API is a fairly minor change, so I did it in scope of https://youtrack.jetbrains.com/issue/JT-61959 that will be included into the next 2020.6.x bugfix release.

Regards,
  Alexander

0
Comment actions Permalink

Hi Alexander,

Thank you very much for the fix, this will make our live a lot easier when it makes its way to YouTrack inCloud!

Unfortunately, I've stumbled upon another Workflow API limitation in the context of improving YouTrack's Help desk support. We are developing a workflow to merge duplicate tickets that would work in the same way as Jira's Merge Agent plugin. To this end, I need to be able to add multiple comments to an issue from within a single workflow call.

YouTrack has a Workflow API called "addComment", but it seems to be adding comments in a random order and there doesn't seem any way to specify in which order I would like the comments to be added. This makes it impossible to copy comments from one issue to another in a chronological sequence.

Again, I could work around this issue by calling YouTrack REST API from the workflow, but this is very cumbersome (see my first post). Is there a solution to this problem that you could offer?

All the best,

Yury

0
Comment actions Permalink

Hi Yury,

You're always welcome.

What you described looks like a bug, I've filed it here and will try to fix in timely manner. The easiest way for you to get updates on the matter is to vote for the issue or just star it.

Thank you for being persistent in your effort to employ YouTrack into your process.

Alexander

0
Comment actions Permalink

Hi Alexander,

Thank you very much for your continued support and opening the issue! I have added another point pertaining to comments being a Set and voted for it.

My persistence in pushing for YouTrack has a trivial background: I'm cornered against the wall ;-) Our lawyers have determined that Jira is not GDPR-compliant and YouTrack inCloud is, and other trackers don't even come close, so... maybe if I succeed, I should start a business doing complex Jira to YouTrack migrations for corporates to get rich and by myself an island.

Jokes aside, YouTrack really feels like Jira done right on many levels, hopefully it will stay true to its roots and stand the test of time. Extensibility is lacking a bit, but the situation is improving and YouTrack Workflows + Custom Fields story is just so much better in terms of design than Jira crazy state machine stuff + weird fields + ScriptRunner. I just wish that I didn't have so much pressure and an ambitious deadline to meet with the migration...

Yury

0
Comment actions Permalink

Hi Alexander,

Sorry to annoy you with another apparent limitation of Workflow API that I have just discovered :-(

Just like Jira, YouTrack supports adding attachments to specific comments. However, IssueComment.attachments is a Set, and a read only one. Issue has a method addAttachment, but this method doesn't allow to specify to which comment the attachment must be added.

It looks like it's only possible to add attachment to a comment using YouTrack REST API by calling /issues/{id}/attachments with comment: { id: } set to comment ID. This means that we can't properly copy comments from one issue to another...

Is there anything that can be done about this? Should I open an issue for it?

All the best,

Yury

0
Comment actions Permalink

Hi Yury,

Thank you for the kind words.

I've exposed a method for adding attachments to issue comments in scope of https://youtrack.jetbrains.com/issue/JT-62046. As the change is rather trivial again, it will be included into the next 2020.6 bugfix.

The added comments order thing is still to be investigated and fixed though.

Regards,
Alexander

0
Comment actions Permalink

Hi Yury,

Writing to inform you that https://youtrack.jetbrains.com/issue/JT-62041 has also been fixed and is to be included into the next 2020.6 bugfix.

Regards,

Alexander

0
Comment actions Permalink

Hi Alexander,

Here I am again: unfortunately, we've found another place in the Workflow API where needed functionality is missing as compared to REST API:

https://www.jetbrains.com/help/youtrack/standalone/v1-IssueComment.html

The REST API has a filed called "deleted", which we can use to check whether the comment has been logically deleted. Unfortunately, this field is missing from the Workflow API. Would it be possible to expose it as well to the Workflows?

Many thanks!

Yury

0
Comment actions Permalink

Hi Jury,

The property has been exposed in scope of https://youtrack.jetbrains.com/issue/JT-62292. Your instance should be updated within a couple of weeks.

Regards,
  Alexander

0
Comment actions Permalink

Hi Alexander,

Thank you once again very much for your help! We have noticed, that our YouTrack inCloud instance was upgraded on Feb, 1 to Build 2020.6.4750 - we are now able to use the new properties exposed as a part of this thread and will be testing other fixes, however the access to user IDs is still missing. I'm unable to open the ticket you linked to (JT-61959) - could you please check whether it really did make it into the bugfix release, and tell me if there are any ETAs as to when it will become available?

All the best,

Yury

0
Comment actions Permalink

Hi Yury,

Sorry, I should have made the issue public. It now is. The property name is ringId. Thank you for your patience.

Regards,
  Alexander

0
Comment actions Permalink

Hi Alexander,

Thanks for the clarification!

We can indeed see ringId, however it's not the internal YouTrack user ID, which the REST endpoints are expecting as "id" (looks like "123-456"), but rather some kind of UUID. However, I have just tried can POST to /issues/{id}/comments with "author": {"ringId" : UUID } instead of "author": {"id": "123-456"} and it seems to have worked ;-)

If that's the "official" way, then that would do the job for us...

All the best,

Yury

0
Comment actions Permalink

Hi Yury,

Yes, absolutely, you can use this ringId throughout the REST API to refer to user and it will work the same way as for ID.

Regards,
  Alexander

0
Comment actions Permalink

Hi there,

Unfortunately, JT-62041 is somehow not completely gone. We are doing something like this:

exports.rule = entities.Issue.onChange({
  guard: ctx => ctx.issue.links[ctx.Duplicate.outward].added.isNotEmpty(),
  action: ctx => {
    ctx.issue.links[ctx.Duplicate.outward].added.forEach(dupIssue => {
  dupIssue.comments.forEach(dupComment => {
issue.addComment(dupComment.text, dupComment.author);
}
}
},
requirements: { Duplicate: { type: entities.IssueLinkPrototype, outward: 'is duplicated by', inward: 'duplicates' },
}
});

Unfortunately, whereas the relative order of comments is preserved, sometimes they are added correctly, and sometimes in reverse. I wasn't able to pinpoint exact conditions so far. It seems that within one project the order is stable, but in a different project the order can be different...

Can something be done about that? Are we doing anything wrong?

All the best,

Yury

 

0
Comment actions Permalink

Hi Yuri,

I'm now investigating the issue. Thank you for your patience.

Regards,
  Alexander

0
Comment actions Permalink

Hi Alexander,

Let me know if you are having trouble reproducing it, I might be able to point you to two inCloud instances with different orders. Need to check it myself first though - not sure whether the projects are already deleted or not.

All the best,

Yury

0
Comment actions Permalink

Hi Alexander,

Just one more question - is it possible to access source mailbox messages for issue or comment via Workflows? I found the API using Inspector: /api/admin/integrations/mailbox/emails/issue/KEY-123 - however it doesn't even seem to be public. This doesn't have much urgency for us, but it would be nice to be able to access message headers when processing incoming helpdesk mails via workflows...

All the best,

Yury

0
Comment actions Permalink

Hello Yury, there was a new fix made in the issue, the build with the fix will be released soon, please watch the updates in the tracker: https://youtrack.jetbrains.com/issue/JT-62041

As for your last comment, I've created a new request in our tracker, please feel free to comment or vote on it: https://youtrack.jetbrains.com/issue/JT-62797

0

Please sign in to leave a comment.