fix(jira): correct Data Sensitivity field ID and replicate Jira's real classification scheme
Aegis CI / lint-and-test (push) Has been cancelled
Snyk Security Scan / Python vulnerabilities (backend) (push) Has been cancelled
Snyk Security Scan / npm vulnerabilities (frontend) (push) Has been cancelled
Snyk Security Scan / Docker image vulnerabilities (backend) (push) Has been cancelled
Aegis CI / lint-and-test (push) Has been cancelled
Snyk Security Scan / Python vulnerabilities (backend) (push) Has been cancelled
Snyk Security Scan / npm vulnerabilities (frontend) (push) Has been cancelled
Snyk Security Scan / Docker image vulnerabilities (backend) (push) Has been cancelled
The auto-create-ticket call was sending customfield_11233 (a field that doesn't exist in the project) instead of the real Data Sensitivity field customfield_11814, which made Jira reject the WHOLE issue and silently block ticket creation for every new test. Also replaces Aegis's invented 4-tier data_classification scheme (public_release/general_use/confidential/restricted) with the 6 values Jira's Data Sensitivity field actually uses (public/general_use/ internal_use_only/trusted_people/customer_content/pii), since that is the classification the organization actually applies. Includes a data migration remapping existing rows and a defensive retry if Jira ever rejects an unscreened custom field again.
This commit is contained in:
@@ -0,0 +1,47 @@
|
||||
"""Rename data_classification values to match Jira's real Data Sensitivity field.
|
||||
|
||||
Jira's actual "Data Sensitivity" custom field (customfield_11814) has 6
|
||||
options — Public, General Use, Internal Use Only, Trusted People, Customer
|
||||
Content, PII — not the 4-tier scheme Aegis invented independently. This
|
||||
migration replicates Jira's scheme so ticket sync stops guessing at a
|
||||
mapping. Applies to tests, campaigns, and evidences tables (all plain
|
||||
String(20) columns — no native enum type to alter).
|
||||
|
||||
public_release -> public, confidential -> internal_use_only,
|
||||
restricted -> pii. general_use is unchanged.
|
||||
|
||||
Revision ID: b060
|
||||
Revises: b059
|
||||
Create Date: 2026-07-09
|
||||
"""
|
||||
|
||||
from alembic import op
|
||||
|
||||
revision = "b060"
|
||||
down_revision = "b059"
|
||||
branch_labels = None
|
||||
depends_on = None
|
||||
|
||||
_TABLES = ("tests", "campaigns", "evidences")
|
||||
|
||||
_RENAMES_UP = {
|
||||
"public_release": "public",
|
||||
"confidential": "internal_use_only",
|
||||
"restricted": "pii",
|
||||
}
|
||||
|
||||
_RENAMES_DOWN = {v: k for k, v in _RENAMES_UP.items()}
|
||||
|
||||
|
||||
def upgrade() -> None:
|
||||
for table in _TABLES:
|
||||
for old, new in _RENAMES_UP.items():
|
||||
op.execute(f"UPDATE {table} SET data_classification = '{new}' WHERE data_classification = '{old}'")
|
||||
op.alter_column(table, "data_classification", server_default="internal_use_only")
|
||||
|
||||
|
||||
def downgrade() -> None:
|
||||
for table in _TABLES:
|
||||
for new, old in _RENAMES_DOWN.items():
|
||||
op.execute(f"UPDATE {table} SET data_classification = '{old}' WHERE data_classification = '{new}'")
|
||||
op.alter_column(table, "data_classification", server_default="confidential")
|
||||
Reference in New Issue
Block a user