Issues, Statuses, Assignments, False Positives, and Resolution Workflow: Configuration, Design Patterns, and Trade-Offs

1. Ask which state should change

If code is wrong, change code. If the analyzer is wrong, False positive may be appropriate. If the finding is valid but deferred, Accepted records that decision. If only ownership is wrong, reassign. If the rule is systematically unsuitable, review profile/scope rather than rewriting hundreds of issue histories.

2. Decision table: source versus workflow versus policy

3. Bulk triage needs a homogeneous rationale

Bulk change can assign, tag, or change status for multiple issues. A large filter result is not evidence that every issue deserves the same disposition. Record the filter/query, count, representative samples, decision criterion, approver, and rollback before applying a bulk action.

4. Temporary exception versus source suppression

In many languages //NOSONAR suppresses all issues on a line, including future ones. That is broader than changing the workflow state of one finding. Prefer issue-level workflow when the decision is about one current finding; prefer profile/scope changes when policy is wrong; use source suppression only when its broad, persistent effect is intentionally reviewed as source code.

5. SCM-assisted assignment versus explicit ownership

Automatic assignment to the last committer can reduce triage latency but should not define organizational accountability. Let SCM seed routing where useful, then explicitly reassign by component/team responsibility. Tags/comments can support workflow, but they are not approvals unless your governance process defines them as such.

6. External issues have another system of record

Imported external findings can be managed in SonarQube, but a SonarQube False positive or assignment does not automatically change the state in the external analyzer. Define which system is authoritative and how reconciliation is audited.

7. Least privilege for issue management

Accepted and False positive require Administer Issues on the project. Do not hand out instance administration merely for triage. A Web API User token has all permissions of its issuing user, so automation should use a narrowly permissioned user plus short token lifetime.

Comments are shared by default but may be disabled globally. Tags can mark reviewed states, but tags are metadata and should not silently become approval policy.

8. Worked scenario: one red gate, four causes

Suppose ten new issues contain four source defects, three valid findings blocked by a dependency migration, two findings from generated code that should be excluded, and one suspected analyzer mistake. The correct response is four different state changes: fix source; Accepted only if deferral policy allows; correct generated-code scope; investigate the suspected false positive with a reproducer. One bulk status action would erase those causal distinctions.

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.