Skip to content

OSIDB-4920: Fix JiraProjectFields unique constraint dupliate names #1248

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
JakubFrejlach wants to merge 1 commit into
base: master
Choose a base branch
from
Draft

OSIDB-4920: Fix JiraProjectFields unique constraint dupliate names #1248

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 17 additions & 0 deletions apps/trackers/migrations/0003_alter_jiraprojectfields_unique_together.py
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,17 @@
# Generated by Django 5.2.12 on 2026-04-16 13:02

from django.db import migrations


class Migration(migrations.Migration):

dependencies = [
('trackers', '0002_jirabugissuetype'),
]

operations = [
migrations.AlterUniqueTogether(
name='jiraprojectfields',
unique_together={('project_key', 'field_id')},
),
Comment on lines +13 to +16
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot Apr 16, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Run on a DB snapshot before applying migration 0003.
# Expected result: zero rows returned.
psql "$DATABASE_URL" -c "
SELECT project_key, field_id, COUNT(*) AS dup_count
FROM trackers_jiraprojectfields
GROUP BY project_key, field_id
HAVING COUNT(*) > 1
ORDER BY dup_count DESC, project_key, field_id;
"

Repository: RedHatProductSecurity/osidb

Length of output: 115

🏁 Script executed:

find . -name "*jiraprojectfields*" -o -name "*migration*" | grep -E "(migration|jiraproject)" | head -20

Repository: RedHatProductSecurity/osidb

Length of output: 522

🏁 Script executed:

cd apps/trackers/migrations && ls -la | grep -E "^-.*\.py$" | head -20

Repository: RedHatProductSecurity/osidb

Length of output: 363

🏁 Script executed:

cat -n apps/trackers/migrations/0003_alter_jiraprojectfields_unique_together.py

Repository: RedHatProductSecurity/osidb

Length of output: 562

🏁 Script executed:

cat -n apps/trackers/migrations/0001_initial.py

Repository: RedHatProductSecurity/osidb

Length of output: 1289

🏁 Script executed:

cat -n apps/trackers/migrations/0002_jirabugissuetype.py

Repository: RedHatProductSecurity/osidb

Length of output: 760

🏁 Script executed:

find . -name "models.py" -path "*/trackers/*" -exec cat -n {} \;

Repository: RedHatProductSecurity/osidb

Length of output: 1066

Add a pre-migration check or cleanup step for the constraint change.

Migration 0003 changes the unique constraint from (project_key, field_name) to (project_key, field_id) without safeguards. Since the initial schema did not enforce uniqueness on field_id alone, existing duplicate pairs could cause deployment failure. Either add a RunPython step in this migration to validate/clean duplicates, or provide an explicit pre-deployment verification command for operators:

SELECT project_key, field_id, COUNT(*) AS dup_count
FROM trackers_jiraprojectfields
GROUP BY project_key, field_id
HAVING COUNT(*) > 1;
🤖 Prompt for AI Agents 
Verify each finding against the current code and only fix it if needed.

In `@apps/trackers/migrations/0003_alter_jiraprojectfields_unique_together.py`
around lines 13 - 16, Migration 0003
(apps/trackers/migrations/0003_alter_jiraprojectfields_unique_together.py)
changes the unique_together on model JiraProjectFields from (project_key,
field_name) to (project_key, field_id) and needs a pre-migration
cleanup/validation step to avoid constraint violations; add a RunPython
operation in that migration (or an accompanying pre-deploy script) that queries
trackers_jiraprojectfields for duplicate (project_key, field_id) pairs, logs or
resolves duplicates (e.g., merge/remove extras or set a canonical field_id), and
only then applies migrations.AlterUniqueTogether to ensure the DB has no rows
that would break the new constraint.

]
2 changes: 1 addition & 1 deletion apps/trackers/models.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ class JiraProjectFields(models.Model):
allowed_values = models.JSONField(default=list)

class Meta:
unique_together = ("project_key", "field_name")
unique_together = ("project_key", "field_id")
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot Apr 16, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Constraint change makes existing field_name lookups ambiguous.

Line 15 allows duplicate (project_key, field_name) rows, but query paths still resolve by field_name and take .first() (see apps/trackers/jira/query.py Lines 762-770, 530-545, and 382-390). That can return the wrong field_id/allowed_values and produce incorrect Jira payload fields.

Please add disambiguation (for example, include issue-type scope in storage/lookups) or fail fast when multiple rows match a field_name.

🤖 Prompt for AI Agents 
Verify each finding against the current code and only fix it if needed.

In `@apps/trackers/models.py` at line 15, The change to unique_together =
("project_key", "field_id") makes lookups by field_name ambiguous; update either
the storage constraint or the query logic: either restore/expand the uniqueness
(e.g., include "field_name" or include issue-type scope) in the model where
unique_together is defined, or modify the lookup paths in
apps/trackers/jira/query.py (the functions that call .first() when resolving
field_name) to detect multiple matches and fail fast (raise a clear error) or
disambiguate using issue-type context; ensure the chosen fix references the
unique_together tuple in models.py and the specific field_name resolution code
in apps/trackers/jira/query.py so lookups return a single, deterministic
field_id/allowed_values.


def __str__(self):
return self.field_name
Expand Down
3 changes: 3 additions & 0 deletions docs/CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,6 +10,9 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
- Affect(s) can be automatically created and assigned to Flaw(s) for
specific products (OSIDB-4878)

### Fixed
- Fix JiraProjectFields unique constraint to use field_id instead of field_name, allowing projects with duplicate field names (OSIDB-4920)

## [5.9.0] - 2026-04-09
### Fixed
- Fix invalid `in` field in kerberos OpenAPI security scheme (OSIDB-1590)
Expand Down
Loading