Bolster cross-linking about confidentiality

We mention confidentiality (for epics, merge requests, and issues)
in various places in our docset, but we rarely linked to the pages
with the actual information. This MR adds in quite a few crosslinks
to ease the friction of finding needed info.

doc/development/iterating_tables_in_batches.md

@@ -334,8 +334,8 @@ end
 The iteration uses the `id` column of the `projects` table. The batching does not affect the
 subquery. This means for each iteration, the subquery is executed by the database. This adds a
 constant "load" on the query which often ends up in statement timeouts. We have an unknown number
-of confidential issues, the execution time and the accessed database rows depend on the data
-distribution in the `issues` table.
+of [confidential issues](../user/project/issues/confidential_issues.md), the execution time
+and the accessed database rows depend on the data distribution in the `issues` table.
 
 NOTE:
 Using subqueries works only when the subquery returns a small number of rows.

doc/development/permissions.md

@@ -86,7 +86,8 @@ is calculated properly.
 
 ### Confidential issues
 
-Confidential issues can be accessed only by project members who are at least
+[Confidential issues](../user/project/issues/confidential_issues.md) can be accessed
+only by project members who are at least
 reporters (they can't be accessed by guests). Additionally they can be accessed
 by their authors and assignees.
 

doc/development/reference_processing.md

@@ -152,7 +152,8 @@ a resource that some subsequent readers should not be able to see.
 
 For example, you might create an issue, and refer to a confidential issue `#1234`,
 which you have access to. This is rendered in the cached HTML as a link to
-that confidential issue, with data attributes containing its ID, the ID of the
+that [confidential issue](../user/project/issues/confidential_issues.md),
+with data attributes containing its ID, the ID of the
 project and other confidential data. A later reader, who has access to your issue
 might not have permission to read issue `#1234`, and so we need to redact
 these sensitive pieces of data. This is what `ReferenceParser` classes do.

doc/operations/incident_management/status_page.md

@@ -124,7 +124,7 @@ To publish an incident:
 1. Create an issue in the project you enabled the GitLab Status Page settings in.
 1. A [project or group owner](../../user/permissions.md) must use the
    `/publish` [quick action](../../user/project/quick_actions.md) to publish the
-   issue to the GitLab Status Page. Confidential issues can't be published.
+   issue to the GitLab Status Page. [Confidential issues](../../user/project/issues/confidential_issues.md) can't be published.
 
 A background worker publishes the issue onto the Status Page using the credentials
 you provided during setup. As part of publication, GitLab:
@@ -168,5 +168,6 @@ To change the incident status from `open` to `closed`, close the incident issue
 within GitLab. Closing the issue triggers a background worker to update the
 GitLab Status Page website.
 
-If you make a published issue confidential, GitLab unpublishes it from your
-GitLab Status Page website.
+If you
+[make a published issue confidential](../../user/project/issues/confidential_issues.md#making-an-issue-confidential),
+GitLab unpublishes it from your GitLab Status Page website.

doc/user/application_security/cve_id_request.md

@@ -28,7 +28,7 @@ If the following conditions are met, a **Request CVE ID** button appears in your
 - The project is hosted in GitLab.com.
 - The project is public.
 - You are a maintainer of the project.
-- The issue is confidential.
+- The issue is [confidential](../project/issues/confidential_issues.md).
 
 ## Submitting a CVE ID Request
 
@@ -37,7 +37,7 @@ the [GitLab CVE project](https://gitlab.com/gitlab-org/cves).
 
 ![CVE ID request button](img/cve_id_request_button.png)
 
-Creating the confidential issue starts the CVE request process.
+Creating the [confidential issue](../project/issues/confidential_issues.md) starts the CVE request process.
 
 ![New CVE ID request issue](img/new_cve_request_issue.png)
 

doc/user/discussions/index.md

@@ -138,6 +138,8 @@ who have at least the Reporter role.
 
 ![Confidential comments](img/confidential_comments_v13_9.png)
 
+You can also make an [entire issue confidential](../project/issues/confidential_issues.md).
+
 ## Show only comments
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/26723) in GitLab 11.5.

doc/user/group/epics/manage_epics.md

@@ -193,7 +193,10 @@ or newest items to be shown first.
 If you're working on items that contain private information, you can make an epic confidential.
 
 NOTE:
-A confidential epic can only contain confidential issues and confidential child epics.
+A confidential epic can only contain [confidential issues](../../project/issues/confidential_issues.md)
+and confidential child epics. However, merge requests are public, if created in a public project.
+Read [Merge requests for confidential issues](../../project/merge_requests/confidential.md)
+to learn how to create a confidential merge request.
 
 To make an epic confidential:
 

doc/user/group/roadmap/index.md

@@ -69,7 +69,7 @@ You can also filter epics in the Roadmap view by the epics':
 - Author
 - Label
 - Milestone
-- Confidentiality
+- [Confidentiality](../epics/manage_epics.md#make-an-epic-confidential)
 - Epic
 - Your Reaction
 

doc/user/permissions.md

@@ -46,7 +46,7 @@ The following table lists project permissions available for each role:
 | Action                                            | Guest   | Reporter   | Developer   |Maintainer| Owner  |
 |---------------------------------------------------|---------|------------|-------------|----------|--------|
 | Assign issues                                     | ✓ (*16*)| ✓          | ✓           | ✓        | ✓      |
-| Create confidential issue                         | ✓       | ✓          | ✓           | ✓        | ✓      |
+| Create [confidential issue](project/issues/confidential_issues.md) | ✓   | ✓  | ✓      | ✓        | ✓      |
 | Create new issue                                  | ✓       | ✓          | ✓           | ✓        | ✓      |
 | Download and browse job artifacts                 | ✓ (*3*) | ✓          | ✓           | ✓        | ✓      |
 | Download project                                  | ✓ (*1*) | ✓          | ✓           | ✓        | ✓      |
@@ -97,7 +97,7 @@ The following table lists project permissions available for each role:
 | [Set issue estimate and record time spent](project/time_tracking.md) | | ✓ | ✓         | ✓        | ✓      |
 | View CI/CD analytics                              |         | ✓          | ✓           | ✓        | ✓      |
 | View Code Review analytics **(PREMIUM)**          |         | ✓          | ✓           | ✓        | ✓      |
-| View confidential issues                          | (*2*)   | ✓          | ✓           | ✓        | ✓      |
+| View [confidential issues](project/issues/confidential_issues.md) | (*2*) |  ✓  | ✓    | ✓        | ✓      |
 | View Error Tracking list                          |         | ✓          | ✓           | ✓        | ✓      |
 | View License list **(ULTIMATE)**                  |         | ✓          | ✓           | ✓        | ✓      |
 | View metrics dashboard annotations                |         | ✓          | ✓           | ✓        | ✓      |
@@ -198,7 +198,7 @@ The following table lists project permissions available for each role:
 | Remove protected branches (*4*)                   |         |            |             |          |        |
 
 1. Guest users are able to perform this action on public and internal projects, but not private projects. This doesn't apply to [external users](#external-users) where explicit access must be given even if the project is internal.
-1. Guest users can only view the confidential issues they created themselves.
+1. Guest users can only view the [confidential issues](project/issues/confidential_issues.md) they created themselves.
 1. If **Public pipelines** is enabled in **Project Settings > CI/CD**.
 1. Not allowed for Guest, Reporter, Developer, Maintainer, or Owner. See [protected branches](project/protected_branches.md).
 1. If the [branch is protected](project/protected_branches.md), this depends on the access Developers and Maintainers are given.
@@ -256,7 +256,7 @@ Read through the documentation on [permissions for File Locking](project/file_lo
 
 ### Confidential Issues permissions
 
-Confidential issues can be accessed by users with reporter and higher permission levels,
+[Confidential issues](project/issues/confidential_issues.md) can be accessed by users with reporter and higher permission levels,
 as well as by guest users that create a confidential issue. To learn more,
 read through the documentation on [permissions and access to confidential issues](project/issues/confidential_issues.md#permissions-and-access-to-confidential-issues).
 

doc/user/project/issues/confidential_issues.md

@@ -45,8 +45,8 @@ system note in the issue's comments.
 ## Indications of a confidential issue
 
 There are a few things that visually separate a confidential issue from a
-regular one. In the issues index page view, you can see the eye-slash icon
-next to the issues that are marked as confidential.
+regular one. In the issues index page view, you can see the eye-slash (**(eye-slash)**) icon
+next to the issues that are marked as confidential:
 
 ![Confidential issues index page](img/confidential_issues_index_page.png)
 
@@ -91,3 +91,6 @@ sees in the project's search results respectively.
 ## Related links
 
 - [Merge requests for confidential issues](../merge_requests/confidential.md)
+- [Make an epic confidential](../../group/epics/manage_epics.md#make-an-epic-confidential)
+- [Mark a comment as confidential](../../discussions/index.md#mark-a-comment-as-confidential)
+- [Security practices for confidential merge requests](https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md#security-releases-critical-non-critical-as-a-developer) at GitLab

doc/user/project/issues/managing_issues.md

@@ -59,7 +59,7 @@ When you're creating a new issue, these are the fields you can fill in:
 
 - Title
 - Description
-- Checkbox to make the issue confidential
+- Checkbox to make the issue [confidential](confidential_issues.md)
 - Assignee
 - Weight
 - [Epic](../../group/epics/index.md)

doc/user/project/merge_requests/confidential.md

@@ -70,4 +70,6 @@ to the public upstream project.
 ## Related links
 
 - [Confidential issues](../issues/confidential_issues.md)
+- [Make an epic confidential](../../group/epics/manage_epics.md#make-an-epic-confidential)
+- [Mark a comment as confidential](../../discussions/index.md#mark-a-comment-as-confidential)
 - [Security practices for confidential merge requests](https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md#security-releases-critical-non-critical-as-a-developer) at GitLab

doc/user/project/merge_requests/getting_started.md

@@ -140,7 +140,7 @@ when merged.
 
 If the issue is [confidential](../issues/confidential_issues.md),
 you may want to use a different workflow for
-[merge requests for confidential issues](../issues/confidential_issues.md#merge-requests-for-confidential-issues)
+[merge requests for confidential issues](confidential.md)
 to prevent confidential information from being exposed.
 
 ### Deleting the source branch