> For the complete documentation index, see [llms.txt](https://docs.sonarsource.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sonarsource.com/sonarqube-cloud/managing-your-projects/issues/editing.md).
# Editing issues
When editing issues in SonarQube Cloud, you can mark as false positive, mark it as reviewed, reopen, assign, tag, and/or comment on an issue.
In SonarQube Cloud, you can change the status of an issue in the following cases:
* If you want to fix the issue later, you can accept an issue. The issue status is then marked as **Accepted**.
* If you think the analysis is mistaken, you can mark it as **False positive**.
* If you want to confirm that the issue is valid, you can select **Confirm**. The issue status is then marked as **Confirmed**, and the issue still impacts the quality gate.
In addition, you can reassign an issue, tag an issue, and comment on an issue. See [SonarQube analysis process](/sonarqube-cloud/discovering-sonarcloud/analysis-process-overview/analysis-process.md) for more information.
{% hint style="info" %}
* You can receive an email notification for issue-related events: see [Subscribing to email notifications](/sonarqube-cloud/managing-your-account/notifications.md).
* You can manage external issues (issues detected by an external tool and imported into SonarQube Cloud) in the same way as internal issues. Be aware that managing an external issue within SonarQube Cloud has no impact on its state in the external tool. For example, when you mark an issue as **False positive** in SonarQube Cloud, it is not reflected in the external tool.
* As you edit issues, the related metrics, for example, number of issues taken into account, will update automatically; as will the quality gate status if it’s relevant. See [Understanding measures and metrics](/sonarqube-cloud/managing-your-projects/metric-definitions.md) for more information.
{% endhint %}
You can edit issues in the UI or resolve them in the code. When resolving issues, we recommend sticking to one method and not mixing the two to avoid potential inconsistencies.
## Editing issues in the UI
### Accepting an issue
You may accept an issue if you decide to fix the issue later provided you have the Administer Issues permission on your project. Note that SonarQube Cloud ignores accepted issues in the quality reports and ratings of the code.
{% hint style="info" %}
You can add a comment to your issue change action. See **Commenting on an issue** below for more information about issue comments.
{% endhint %}
To accept an issue:
1. Retrieve the issue. See [Retrieving issues](/sonarqube-cloud/managing-your-projects/issues/retrieving.md) for more information.
2. In the issue card, select the **Open** issue status, then select **Accept** in the **Change issue status** menu. A **Status change comment** box appears.
3. Enter your change comment (optional) and select **Change status**. The issue status is changed to **Accepted**.
### Marking an issue as False positive
If the analysis is mistaken, you can mark an issue as False positive provided you have the Administer Issues permission on your project. Note that SonarQube Cloud ignores False positive issues in the quality reports and ratings of the code.
{% hint style="info" %}
You can add a comment to your issue change action. See **Commenting on an issue** below for more information about issue comments.
{% endhint %}
To mark an issue as False positive:
1. Retrieve the issue. See [Retrieving issues](/sonarqube-cloud/managing-your-projects/issues/retrieving.md) for more information.
2. In the issue card, select the **Open** issue status, then select **False positive** in the **Change issue status** menu. A **Status change comment** box appears.
3. Enter your change comment (optional) and select **Change status**. The issue status is changed to **False positive**.
### Reopening an issue
You can reopen an Accepted issue when it’s time to fix it, reopen a False positive issue if it turns out to be a true positive, or reopen a Confirmed issue.
To reopen one or several issues:
1. Retrieve the issue. See [Retrieving issues](/sonarqube-cloud/managing-your-projects/issues/retrieving.md) for more information.
2. In the issue card, select the **Accepted**, **False positive**, or **Confirmed** issue status, then select **Open** in the **Change issue status** menu. The issue status is reset to **Open**.
### Marking an issue as reviewed
To mark issues as reviewed, you may use the tagging feature: create the Reviewed tag and assign it to reviewed issues: see **Tagging an issue** below. This way, you can filter the reviewed issues by using the Tag filter.
### Assigning an issue
When possible, SonarQube Cloud assigns a default assignee at issue creation time, see [SonarQube analysis process](/sonarqube-cloud/discovering-sonarcloud/analysis-process-overview/analysis-process.md) for more information. You can assign an unassigned issue to a user, reassign an issue to another user, or unassign an issue.
To assign an issue:
1. Retrieve the issue. See [Retrieving issues](/sonarqube-cloud/managing-your-projects/issues/retrieving.md) for more information.
2. In the issue card, select the assignee's name or the **Not assigned** mention. The list of users to whom you can assign the issue appears.
3. In the list, select the new assignee or select **Not assigned** in the list to unassign the issue.
### Tagging an issue
You can create tags and assign them to issues to retrieve them more easily or to indicate a workflow step. For example, you can use a tag to mark an issue as reviewed.
{% hint style="info" %}
Rules can also be tagged (In particular, [Built-in rule tags](/sonarqube-cloud/standards/managing-rules/built-in-rule-tags.md) may be assigned to some rules and your Quality Standards administrator can assign custom ones). An issue inherits the tags assigned to the rule that raised the issue. You can remove the inherited tags.
{% endhint %}
To manage the tags assigned to an issue:
1. Retrieve the issue. See [Retrieving issues](/sonarqube-cloud/managing-your-projects/issues/retrieving.md) for more information.
2. In the search results list or in the detail view, select the **+** icon next to the issue's tags. The **Edit Tags** list opens with the existing tags.
3. In the **Edit Tags** list, you can use the search field to search for an existing tag. To create a new tag, enter the new tag in the search field: the new tag will appear in the list of tags with a plus sign in front of it.
4. To assign or unassign a tag, select or clear the tag’s checkbox in the list.
5. Click anywhere outside the list to close it.
### Commenting on an issue
When accepting an issue or marking an issue as **False positive**, you can add a comment. You can also add a comment to an issue anytime. These comments are visible from the **Activity** tab of the issue: see **Viewing the issue management history and comments** in [Reviewing issues](/sonarqube-cloud/managing-your-projects/issues/reviewing.md).
By default, comments are shared between all users. They can be disabled at the global level.
To add a comment to an issue:
1. Retrieve the issue and open its detail view. See [Retrieving issues](/sonarqube-cloud/managing-your-projects/issues/retrieving.md) for more information.
2. Open the **Activity** tab.
3. Select **Add a comment**. The "Add a comment" dialog box opens.
4. Enter your comment and select **Comment**.
5. Your comment is added to the **Activity** tab.
### Editing several issues in bulk
To edit several issues at once:
1. Select issues individually, or select the checkbox next to **Change** to select all issues. You can deselect the issues you do not want to include.
2. Select **Change** to open a modal.
3. In the modal, select the actions you want to apply:
* **Assign**: Assign the issues to a user.
* **Add tags**: Add tags to the issues.
* **Remove tags**: Remove tags from the issues.
* **Change status**: Accept the issues, mark them as false positive, or confirm them. If the status of the selected issues was already changed, you can also reopen them.\
After you select a status, you can add an optional comment in **Status change comment**. Additionally, you can share the comment with Sonar to help improve the analysis.
4. Select **Apply** to finish.
## Resolving issues in the code
Many teams choose to edit issues in the code so that changes are version-controlled, go through the usual review process, and stay aligned with the actual state of the repository.
### sonar-resolve
Using the `sonar-resolve` keyword in a comment, you can resolve issues from specific rules directly in your code by accepting the issues or marking them as false positive.
`sonar-resolve` is useful when you subcontract development, because it lets you encode issue decisions directly in the code, where external developers will see them. By putting those decisions in code comments, SonarQube Cloud’s issue status stays aligned with what the code actually represents, since `sonar-resolve` is evaluated on every analysis and takes precedence over previous issue state.
Supported languages: C/C++/Objective-C.
The use of `sonar-resolve` must be enabled for your project. See [Other advanced procedures](/sonarqube-cloud/managing-your-projects/administering-your-projects/advanced-administration/other-advanced-procedures.md#in-code-issue-resolution) for more information.
Each annotation has the form `sonar-resolve [status] ruleKey(s) comment` and must specify:
* an optional resolution status in brackets: `[accept]` (default) or `[fp]`. When present, it comes first, before the rule keys. Omitting it is equivalent to `[accept]`.
* at least one rule key (e.g. `cpp:S4962`); separate multiple keys with commas (e.g. `cpp:S100,cpp:S4962`)
* a mandatory comment
#### **Example: Accept**
```cpp
void foo(char* argv[]) {
if (argv != 0) { // sonar-resolve cpp:S4962 "just because I can"
cout << "argv not null\n";; // intentional extra-semicolon
}
}
```
#### **Example: False positive**
```cpp
void foo(char* argv[]) {
if (argv != 0) { // sonar-resolve [fp] cpp:S4962 "just because I can"
cout << "argv not null\n";; // intentional extra-semicolon
}
}
```
> **Note:** For Security Hotspots, the resolution status doesn't matter — `[accept]`, `[fp]`, and omitting the status all resolve the hotspot as **Safe**. SonarQube Cloud doesn't have an **Acknowledged** status for hotspots.
The philosophy here is that the code should not lie. If enabled, `sonar-resolve` has priority on the previous state of the issue when the code is scanned.
If an existing issue is resolved in the code with `sonar-resolve`, and `sonar-resolve` is disabled or the specific `sonar-resolve` is removed, the issue is reopened by the next analysis.
## Suppressing issues
In all languages except Dockerfile, you can use the `//NOSONAR` comment at the end of a line to suppress all issues on that line.
However, we recommend not to use this approach as it creates a significant blind spot in your code analysis. `//NOSONAR` indiscriminately suppresses every issue (current and future) on a given line, regardless of its nature or severity. While your intention might be to simply silence a minor formatting warning, you risk inadvertently masking a critical security vulnerability.
## Related pages
* [Fixing issues](/sonarqube-cloud/managing-your-projects/issues/fixing.md)
* [Adding tags to a rule](/sonarqube-cloud/standards/managing-rules/adding-tags-to-rule.md)
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.sonarsource.com/sonarqube-cloud/managing-your-projects/issues/editing.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
