Using YouTrack's own REST API from within a Workflow

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hi Yuri,

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

Regards,
  Alexander

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

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

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

Hi Liubov,

Thank you very much for the update!

Meanwhile hit another limitation as compared to Jira: the reporter of an already created issue cannot be changed - the Workflow field is read-only and API simply ignores corresponding POSTs. For more background see: https://youtrack.jetbrains.com/issue/JT-6248 and https://youtrack.jetbrains.com/issue/JT-16979 .

All the best,

Yury

Hello Yury!

That's correct, you can't change the reporter of an already created issue, unfortunately.

What I can suggest in this case:

a) Set the reporter at the issue creation. While after that the reporter value is read-only, you can still set it when you create an issue.

b) Create a separate custom field that would act as an additional "reporter" field. With the help of custom workflows, you'll be able to then restrict the visibility of the issues based on this field.

I hope this helps. Let us know if you have any further concerns or questions, we're always happy to help.

Hi Liubov,

Thanks for the suggestions - unfortunately they don't address the use case described in JT-6248 - namely to be able use YouTrack REST APIs directly from web apps instead of wrapping them in lambdas just to conceal tokens. Hopefully one day you'll get to addressing that :-)

All the best,

Yury

Sure, this particular concern is still to be addressed within the issue JT-6248, you are right.

We'll post it to the issue when we have updates on this matter.

Thank you again for your feedback and other input! Don't hesitate to write us if you have any other concerns.

We wish you a nice week.