fix(integrations): Fix incorrect organization for external issues (#48050)

Context: [WOR-2860](https://getsentry.atlassian.net/browse/WOR-2860)

A project transfer led to missing JIRA-linked issues. This migration
should change the organization_id for these issues to the correct org.

I'll add some logging around this as a followup to investigate why/how
this happened and catch it in the future.

[WOR-2860]:
https://getsentry.atlassian.net/browse/WOR-2860?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ

Author: snigdhas

migrations_lockfile.txt

@@ -6,5 +6,5 @@ To resolve this, rebase against latest master and regenerate your migration. Thi
 will then be regenerated, and you should be able to merge without conflicts.
 
 nodestore: 0002_nodestore_no_dictfield
-sentry: 0428_backfill_denormalize_notification_actor
+sentry: 0429_fix_broken_external_issues
 social_auth: 0001_initial

src/sentry/migrations/0429_fix_broken_external_issues.py

@@ -0,0 +1,45 @@
+# Generated by Django 2.2.28 on 2023-04-25 23:51
+
+from django.db import migrations
+
+from sentry.new_migrations.migrations import CheckedMigration
+
+
+def fix_broken_external_issues(apps, schema_editor):
+    ExternalIssue = apps.get_model("sentry", "ExternalIssue")
+
+    # Broken issues from redash: https://redash.getsentry.net/queries/4012/source
+    broken_ids = [636683, 636687, 636692]
+    old_organization_id = 443715
+    new_organization_id = 5417824
+    for issue in ExternalIssue.objects.filter(
+        id__in=broken_ids, organization_id=old_organization_id
+    ):
+        issue.organization_id = new_organization_id
+        issue.save()
+
+
+class Migration(CheckedMigration):
+    # This flag is used to mark that a migration shouldn't be automatically run in production. For
+    # the most part, this should only be used for operations where it's safe to run the migration
+    # after your code has deployed. So this should not be used for most operations that alter the
+    # schema of a table.
+    # Here are some things that make sense to mark as dangerous:
+    # - Large data migrations. Typically we want these to be run manually by ops so that they can
+    #   be monitored and not block the deploy for a long period of time while they run.
+    # - Adding indexes to large tables. Since this can take a long time, we'd generally prefer to
+    #   have ops run this and not block the deploy. Note that while adding an index is a schema
+    #   change, it's completely safe to run the operation after the code has deployed.
+    is_dangerous = False
+
+    dependencies = [
+        ("sentry", "0428_backfill_denormalize_notification_actor"),
+    ]
+
+    operations = [
+        migrations.RunPython(
+            fix_broken_external_issues,
+            reverse_code=migrations.RunPython.noop,
+            hints={"tables": ["sentry_externalissue"]},
+        ),
+    ]

tests/sentry/migrations/test_0429_fix_broken_external_issues.py

@@ -0,0 +1,21 @@
+from sentry.models.integrations.external_issue import ExternalIssue
+from sentry.testutils.cases import TestMigrations
+
+
+class FixBrokenExternalIssues(TestMigrations):
+    migrate_from = "0428_backfill_denormalize_notification_actor"
+    migrate_to = "0429_fix_broken_external_issues"
+
+    def setup_initial_state(self):
+        self.valid_external_issue = ExternalIssue.objects.create(
+            organization_id=5417824, integration_id=1
+        )
+        self.broken_external_issue = ExternalIssue.objects.create(
+            id=636683, organization_id=443715, integration_id=2
+        )
+
+    def test(self):
+        self.broken_external_issue.refresh_from_db()
+        self.valid_external_issue.refresh_from_db()
+        assert self.broken_external_issue.organization_id == 5417824
+        assert self.valid_external_issue.organization_id == 5417824