Page MenuHomePhabricator

Support updating JIRA custom field when revisions change status
Open, WishlistPublic

Description

At the moment the integration with JIRA just posts comments to the JIRA issues that the revision is linked against. It would be great if Phabricator could set the contents of a custom field based on how many revisions are awaiting review / revision / closed. This would give a better overview as to the status of a JIRA issue.

It should be possible with /rest/api/2/issue/{issueIdOrKey} and a config item for configuring what field should be set. It might be required to have two fields, one that gives an overview of the status of the differential revisions, and one that simply toggles between "Not Reviewed", "Awaiting Review" and "Reviewed". The reason for the latter is so that workflows can be restricted from moving to the next status until there is at least one code review done against the item. I'd imagine the overview field would be more along the lines of "2 Awaiting Review, 1 Awaiting Revision, 3 Accepted" etc. where the purpose of this field is just for human readability.

Event Timeline

epriestley triaged this task as Wishlist priority.Sep 16 2013, 10:56 PM
epriestley added a subscriber: epriestley.

Hrrm, I guess this isn't actually realllllly related to or dependent on that.

chad changed the visibility from "All Users" to "Public (No Login Required)".

@hach-que, were you able to move forward with implementation of what you've proposed?

  1. Currently I'm actually working on some code (in my local fork), that would allow to:
    • enter custom field names on JIRA provider configuration screen
    • validate field existence (and retrieve their JIRA internal id for later use) against currently edited JIRA instance
    • place full url to Differential Revision in Jira issue custom field
  2. Are you sure, that there can be several Differential Revisions associated with a particular task? Currently I'm presuming that only 1 revision is associated with Jira task (there is nice "URL" custom field type for that). Not sure if there is "multiple urls" custom field in JIRA.

We never implemented this locally.

eadler added a project: Restricted Project.Mar 24 2016, 7:55 PM
eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Mar 24 2016, 7:55 PM
eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Apr 7 2016, 6:07 PM
eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.May 13 2016, 9:54 PM
eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.May 21 2016, 4:05 PM
eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.May 22 2016, 6:40 PM
eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.
eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jun 1 2016, 10:39 PM
eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.
eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jul 4 2016, 8:59 PM
eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.

If anyone else is looking for this, we have this extension in our local install P2019, which does custom things to a JIRA ticket based on Revisions.

Looks like the JIRA's default door keeper worker. I guess it is automatically discovered when you run arc liberate command.

In my fork I've specified review/accept/reject JIRA transitions and when Differential Revision status is changed I've transition connected JIRA issue.

AutoTransitionJiraIssueBasedOnPhabricator.png (452×1 px, 84 KB)

how could you do this?
i cant find this configuration in my phabricator application

That's why I said In my fork. This is custom code.

Originally I've developed it in https://github.com/aik099/phabricator/tree/T6142-jira-transitions-support , but after a Phabricator update I had to change a lot based on a code, that never existed at time I've created a fork and I was forced to change code right in master branch of my fork. If you know Phabricator code you can easily backport only these changes to your fork. If you don't, then your best bet would be to using my fork as-as. Keep in mind, that you might need to use also forked versions of arcanist and libphutil.