JIRA services break non-gracefully when moving from 7.2 to 7.9

Dev: https://dev.gitlab.org/gitlab/gitlab-ee/issues/283

Large Customer

ZenDesk https://gitlab.zendesk.com/agent/tickets/2347

Jacob

In the past (at least in 7.2-ee), JIRA integration was an EE-only feature. The JIRA project service did not have a lot of mandatory fields. Then at some point, our old site-wide JIRA integration got converted into a project service. Now if you had the old EE JIRA service enabled for a project, you end up with an invalid configuration on your new JIRA service once you upgrade to 7.9, because it misses the Issues url and New issue url fields.

Proposed fix

Add a DB migration that loops through all JiraServices. If the properties hash is missing values that we now know to be required ('issues url', 'new issue url'), then set the JiraService to disabled in the DB.

Result: the user is forced to re-enable their JiraService, and gets validation errors for the missing fields.

---

Jacob

This is probably hard to fix automagically because we would not know what JIRA settings to fill in in the service.

How can we help GitLab admins fix projects with broken JIRA integration on their server?

Customer does not have very specific information about where in the UI the 500s appeared

Customer

As for what url, the only thing the user mentioned was that he saw the 500 error when "looking into Commits, Branches, and Tags".

This issue only affects EE users who were using automatic JIRA ticket closing, so in that sense the impact is small. On the other hand, it looks pretty bad. We punish those people for using that EE future by giving them 500 errors after an upgrade.

I think this needs to be fixed.

Marin

I agree that bug needs to be fixed but what exactly?

Jacob

Maybe a migration that looks for JIRA services with missing fields, and disables them if required settings are missing? Then when the project owner tries to turn it back on, they get a validation error (I hope) and they know what to fix.

My hope is that if the service is disabled, the 500 errors go away.

Marin

if the service is disabled then the error should go away. Enabling the service again should give the validation errors. (Sorry about the late response, only got the email now).

Jacob

OK I think we should add this migration then. cc dzaporozhets

Dmitriy

+1 for 'Proposed fix'.

unless jira_service.valid?
  jira_service.disable!
end

Jacob

BTW the fix should probably be written without referring to valid?, disable, using SQL instead.

Patricio

8.1 came and went and this one is still open. Is it still relevant?

Marin

I think not, we broke introduced new fixes to Jira service since then.

Patricio

Can you please confirm it is OK to close this one?

cc/ @patricio @dzaporozhets @jacobvosmaer @marin @sytses @DouweM

mentioned in commit 483c0e26

Milestone changed to 8.6

I don't think this is an issue anymore, like Marin says we've made a lot of changes to JIRA since then.

Status changed to closed

Mentioned in commit 483c0e26

mentioned in commit 8e984b80

mentioned in commit d1e97cdb