Allow me to set multiple Jira Server states for "resolved"

[jboulter11]

Problem Statement

Right now I can only set one state for Jira tickets to be marked resolved.

I'd like to be able to set multiple, and here's my use case.

I have users who set Jira tickets to one of three end states: Done (fixed, finished), Cancelled (Won't do, not finished), and Duplicate (The same as another jira ticket).

If a user sets their ticket to Cancelled or Duplicate, the Sentry issue stays open and the link becomes mostly useless. If that issue gets worse, or triggers some other alert, it won't make a new Jira ticket or re-open the old one. We won't be notified in Jira about the issue anymore. This is how we lose issues and important work goes undone because the Jira ticket gets lost.

I'd like to force my users to effectively not use Cancelled or Duplicate while a Jira ticket is still linked to Sentry. I want Sentry to be able to raise another Jira ticket or re-open the existing, if a ticket is marked as Cancelled or Duplicate. If those states in Jira set the Sentry ticket to resolved, it'll open it back up when it's not actually fixed, and we won't lose the Jira ticket linked to the Sentry issue.

Here's the logic I'm using when I think about this:

• If the ticket is cancelled, usually because it's low priority or won't get worked, why did it get created as a Jira ticket in the first place? The alerts should probably be adjusted, and the link removed so they can open a new ticket in the future.
  • If the alerts are not to blame, but the issue is not high priority, then the error log should be removed entirely, clearly it's not important enough to be wasting quota on.
• If the ticket is actually a duplicate of another Sentry issue, it should then be merged in Sentry, where the parent issue's Jira ticket would then be tracking the issue.

Solution Brainstorm

Allow me to correlate more than one Jira state to Resolved in Sentry.

As an alternative, I'd be open to the ability to re-open existing tickets based on alerts or escalating issues.

Perhaps it would be nice if we had some way to define our own custom logic for this plugin. A plugin for the plugin or something, so we could just write some functions for hooks like:

• sentryIssueResolved
• sentryIssueRegressed
• jiraTicketChangedState

Ideally we'd have APIs to:

• comment on the Jira ticket and Sentry issue activity
• change the properties of the Jira ticket and set the state of the Sentry issue

And then we could decide what to do without needing to re-write the whole integration.

I recognize I'm definitely prescribing strongly here, I'm very open to other solutions which don't involve this mechanism, but help us not lose Sentry/Jira issues in backlogs or bad terminal states which prevents Sentry notifying us in Jira about issues hitting other alerts or otherwise getting much worse.

Product Area

Settings - Integrations

[getsantry]

Assigning to @getsentry/support for routing ⏲️

[getsantry]

Routing to @getsentry/product-owners-settings-integrations for triage ⏲️