Issues, Statuses, Assignments, False Positives, and Resolution Workflow: Core Concepts and Mental Model

1. Findings need decisions, not cosmetic closure

Static analysis can create findings faster than a team can responsibly remediate them. The operational problem is therefore not merely “how do I close an issue?” It is how to preserve revision, rule, location, owner, decision, rationale, and reanalysis evidence so another engineer can reconstruct why the signal changed.

Marking an issue Accepted or False positive changes SonarQube-managed workflow state. It does not edit Git. Likewise, changing source does not prove the SonarQube issue is fixed until a later analysis processes that revision and no longer detects the finding.

2. Mental model: finding to governed evidence

flowchart TD
A[Analyzed revision] --> B[Rule finding / issue identity]
B --> C[Triage + ownership]
C --> D{Decision}
D -->|Fix source| E[New revision]
D -->|Accept temporarily| F[Workflow metadata + rationale]
D -->|False positive only if analyzer is wrong| G[Workflow metadata + rationale]
E --> H[Reanalysis]
F --> H
G --> H
H --> I[Issue lifecycle + Activity history]
I --> J[Measures / gate / governance evidence]

Issue identity ties a finding to a project, rule, and code location. Assignee expresses current workflow ownership. Accepted and False positive are dispositions, not substitute commits. Reanalysis reconciles the newest source with durable server state.

3. Current Community Build lifecycle

The UI may use an action such as Resolve while changing a status, but “Resolved” is not the current durable status model. Legacy Confirmed, Won’t Fix, Closed, and old resolution fields belong to earlier SonarQube generations.

4. Do not blur these state stores

5. SCM author is not remediation ownership

SonarQube can correlate SCM metadata to users and automatically assign a new issue to the last committer on the affected line. That is useful routing evidence, but the last committer may only have moved code, performed a refactor, or inherited an older defect.

Use the assignee field to express who owns the next action. Preserve reassignment history. A good policy can use SCM-assisted assignment as a starting signal while allowing explicit team/component ownership to override it.

6. Accepted and False positive are high-impact metadata

Current Community Build ignores Accepted and False positive issues in quality reports and ratings. Related measures and a relevant quality gate can therefore update without any Git revision change.

Use Accepted for a valid finding that is deliberately deferred/not fixed now; record a reason, owner, and review condition. Use False positive only when the analyzer is actually mistaken for the code/context. “We do not want to fix it” is not a false positive.

These status changes require the project’s Administer Issues permission and can be reopened. Rollback should restore current state while preserving Activity history.

7. Read-only inspection first

1. Record project key, Git SHA, analysis date, and task evidence.
2. Filter project Issues to the current Open population.
3. For one issue record issue key, rule key, file/line, message, impact/severity, author, and assignee.
4. Read the rule details before deciding the analyzer is wrong.
5. Open the issue Activity tab and preserve current history.
6. Record the current quality gate and the condition actually relevant to the finding population.
7. Only then decide whether the next action belongs in source, workflow, quality policy, or ownership routing.

8. Why this matters in DevOps

Release policy is trustworthy only when its exceptions are governed. SonarQube issue workflow sits between automated detection and human remediation: it can route work and preserve rationale, or it can become a way to suppress inconvenient findings.

The production invariant for this chapter is revision + issue identity + decision + owner + evidence + reanalysis. Chapter 11 will enforce quality gates on top of these signals, so issue workflow must be auditable first.

Knowledge check

Official references and version notes

• Issues introduction — current issue concepts and lifecycle entry points.
• Issue management solution — identification, SCM-assisted assignment and lifecycle.
• Editing issues — Accepted/False positive, reopening, assignment, tags, comments and bulk changes.
• Retrieving issues — current issue filtering and review UI.
• Web API — bearer authentication and Web API V2 migration guidance.
• Managing tokens — token types, API use and revocation.
• SonarQube releases — dated release identities.
• SonarScanner CLI 8.1.0.6389 — scanner baseline.