review

Signed-off-by: Michal Maléř <mmaler@redhat.com>

modules/administration-guide/partials/proc_adding-a-custom-plug-in-registry-in-an-existing-che-workspace.adoc

@@ -57,11 +57,11 @@ The `setting.json` file is displayed.
 
 . Add a new plug-in registry using the `chePlugins.repositories` attribute as shown below:
 +
-[source,yaml]
+[source,yaml,subs="+macros,attributes"]
 ----
 {
 “application.confirmExit”: “never”,
-“chePlugins.repositories”: {“test”: “++https++://test.com”}
+“chePlugins.repositories”: {“test”: “pass:c,m,a,q[+https+://test.com]”}
 }
 ----
 

modules/administration-guide/partials/proc_configuring-bitbucket-server-oauth1.adoc

@@ -12,7 +12,7 @@ pass:[<!-- vale IBM.Headings = YES -->]
 This procedure describes how to activate OAuth 1 for Bitbucket Server to:
 
 * Use devfiles hosted on a Bitbucket Server.
-* xref:end-user-guide:authentication-against-bitbucket-server-with-the-personal-access-token.adoc[].
+* xref:end-user-guide:authenticating-on-scm-server-with-a-personal-access-token.adoc[].
 
 It enables {prod-short} to obtain and renew link:https://confluence.atlassian.com/bitbucketserver/personal-access-tokens-939515499.html[Bitbucket Server Personal access tokens].
 
@@ -121,4 +121,4 @@ Public Key:: Paste the content of the `__<public-stripped.pub>__` file.
 * link:https://confluence.atlassian.com/bitbucketserver/personal-access-tokens-939515499.html[Bitbucket Server Personal access tokens]
 * link:https://confluence.atlassian.com/jirakb/how-to-generate-public-key-to-application-link-3rd-party-applications-913214098.html[How to generate public key to application link 3rd party applications]
 * link:https://confluence.atlassian.com/adminjiraserver/using-applinks-to-link-to-other-applications-938846918.html[Using AppLinks to link to other applications]
-* xref:end-user-guide:authentication-against-bitbucket-server-with-the-personal-access-token.adoc[].
+* xref:end-user-guide:authenticating-on-scm-server-with-a-personal-access-token.adoc[].

modules/end-user-guide/pages/authentication-against-scm-server-with-the-personal-access-token.adoc

@@ -1,5 +1,5 @@
-[id="authentication-against-scm-server-with-the-personal-access-token"]
-// = Authentication against SCM  Server with the personal access token
+[id="authenticating-on-scm-server-with-a-personal-access-token"]
+// = Authenticating users on private repositories of SCM servers
 :navtitle: Authentication against SCM Server with the personal access token
 :keywords: end-user-guide, authentication-against-scm-server-with-the-personal-access-token
 :page-aliases: .:authentication-against-scm-server-with-the-personal-access-token

modules/end-user-guide/partials/assembly_authenticating-on-scm-server-with-a-personal-access-token.adoc

@@ -5,9 +5,18 @@
 [id="authenticating-on-scm-server-with-a-personal-access-token_{context}"]
 = Authenticating users on private repositories of SCM servers
 
-*xref:configuring_bitbucket_authentication.adoc[]
-*xref:configuring_gitlab_authentication.adoc[]
+
+The following section describes how to configure user authentications for SCM servers.
+
+* xref:configuring_gitlab_authentication_{context}[]
+
+* xref:configuring_bitbucket_authentication_{context}[]
+
+
 
 include::partial$proc_configuring_bitbucket_authentication.adoc[leveloffset=+1]
 
-include::partial$proc_configuring_gitlab_authentication.adoc[leveloffset=+1]
+include::partial$proc_configuring_gitlab_authentication.adoc[leveloffset=+1]
+
+
+:context: {parent-context-of-authenticating-on-scm-server-with-a-personal-access-token}

modules/end-user-guide/partials/proc_configuring_bitbucket_authentication.adoc

@@ -1,18 +1,18 @@
-// configuring-bitbucket-authentication
+// Module included in the following assemblies:
+//
+// authenticating-on-scm-server-with-a-personal-access-token
 
 [id="configuring_bitbucket_authentication_{context}"]
 = Authenticating on Bitbucket servers
 
 {prod} users may use public or private repositories on Bitbucket SCM (Source Code Management) system as a source of their projects.
 
-The use of private repositories, requires some additional configuration described below.
+The use of private repositories requires additional configuration described below.
 
-Bitbucket authentication is based on using personal access tokens. Each Bitbucket user is able to request some
-amount of personal access tokens with different names, permissions, expiration times, and so on. Those tokens
-can be used to sign Bitbucket REST API calls and perform Git repository operations.
+Bitbucket authentication is based on using personal access tokens. Each Bitbucket user is able to request several personal access tokens with different names, permissions, expiration times, and so on. Those tokens can be used to sign Bitbucket REST API calls and perform Git repository operations.
 
-To allow Bitbucket authentication on {prod} side, personal tokens must be stored in user's namespace in a form of
-secret. The secret must look as follows:
+To allow Bitbucket authentication on {prod-short} side, personal tokens must be stored in the user's namespace in the form of
+a secret. The secret must look as follows:
 
 [source,yaml]
 ----
@@ -58,19 +58,18 @@ NOTE: Encoding a string into the base64 format using the `base64` tool on Linux
 . To obtain a user ID from a secret using a call to a REST API URL:
 *  For Bitbucket:
 +
-[subs="+quotes"]
+[subs="+quotes,macros"]
 ----
-https://__<bitbucket-hostname>__/rest/api/1.0/users/__<username>__
+++https++://__<bitbucket-hostname>__/rest/api/1.0/users/__<username>__
 ----
 
 * For {prod-short}
 +
-[subs="+attributes,+quotes"]
+[subs="+macros,attributes"]
 ----
 {prod-url}/api/user
 ----
 
 * With the token credentials obtained from a secret, another secret is automatically created, allowing authorization to Git operations. This secret is mounted into a workspace container as a Git credentials file, and any additional configurations are not required to work with private Git repositories.
 
-* When a remote Git repository uses a self-signed certificate, add an additional server configuration. See:
-xref:installation-guide:deploying-che-with-support-for-git-repositories-with-self-signed-certificates.adoc[].
+* When a remote Git repository uses a self-signed certificate, add an additional server configuration. See xref:installation-guide:deploying-che-with-support-for-git-repositories-with-self-signed-certificates.adoc[].

modules/end-user-guide/partials/proc_configuring_gitlab_authentication.adoc

@@ -1,18 +1,18 @@
-// configuring-gitlab-authentication
+// Module included in the following assemblies:
+//
+// authenticating-on-scm-server-with-a-personal-access-token
 
 [id="configuring_gitlab_authentication_{context}"]
 = Authenticating on GitLab servers
 
-Configuring authentication on GitLab system is a very similar to Bitbucket.
+Configuring authentication on the GitLab system is similar to Bitbucket.
 
-GitLab authentication is based on using personal access tokens. Each GitLab user is able to request some
-amount of personal access tokens with different names, permissions, expiration times, and so on. Those tokens
-can be used to sign GitLab REST API calls and perform Git repository operations.
+GitLab authentication is based on using personal access tokens. Each GitLab user is able to request several personal access tokens with different names, permissions, expiration times, and so on. Those tokens can be used to sign GitLab REST API calls and perform Git repository operations.
 
-See https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#personal-access-tokens[GitLab documentation] for more details about personal access tokens.
+See the link:https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#personal-access-tokens[GitLab documentation] for more details about personal access tokens.
 
-To allow GitLab authentication on {prod} side, personal tokens must be stored in user's namespace in a form of
-secret. The secret must look as follows:
+To allow GitLab authentication on {prod-short} side, personal tokens must be stored in the user's namespace in the form of
+a secret. The secret must look as follows:
 
 [source,yaml]
 ----
@@ -58,14 +58,14 @@ NOTE: Encoding a string into the base64 format using the `base64` tool on Linux
 . To obtain a user ID from a secret, take a look into user profile page on GitLab web UI or make a call to a REST API URL:
 *  For GitLab:
 +
-[subs="+quotes"]
+[subs="+quotes,macros"]
 ----
-https://__<gitlab-hostname>__/api/v4/users?username=__<username>__
+++https++://__<gitlab-hostname>__/api/v4/users?username=__<username>__
 ----
 
 * For {prod-short}
 +
-[subs="+attributes,+quotes"]
+[subs="+macros,attributes"]
 ----
 {prod-url}/api/user
 ----