pr review comments 1

Author: phil198

modules/ROOT/pages/authentication-authorization/manage-privileges.adoc

@@ -45,7 +45,9 @@ The components of the graph privilege commands are:
 ** `REVOKE` – removes granted or denied privileges from roles.
 
 * _mutability_:
-** `IMMUTABLE` can optionally be specified when performing a `GRANT` or `DENY` to indicate that the privilege cannot be subsequently removed unless auth is disabled. Auth must also be disabled in order to `GRANT` or `DENY` an immutable privilege. Contrastingly, when `IMMUTABLE` is specified in conjunction with a `REVOKE` command, it will act as a filter and only remove matching _immutable_ privileges. See also xref:authentication-authorization/privileges-and-roles-immutable.adoc[].
+** `IMMUTABLE` can optionally be specified when performing a `GRANT` or `DENY` to indicate that the privilege cannot be subsequently removed unless auth is disabled.
+Auth must also be disabled in order to `GRANT` or `DENY` an immutable privilege (details xref:authentication-authorization/privileges-and-roles-immutable.adoc#access-control-privileges-immutable-admin[here]).
+Contrastingly, when `IMMUTABLE` is specified in conjunction with a `REVOKE` command, it will act as a filter and only remove matching _immutable_ privileges.
 
 * _graph-privilege_:
 ** Can be either a xref:authentication-authorization/privileges-reads.adoc[read privilege] or xref:authentication-authorization/privileges-writes.adoc[write privilege].

modules/ROOT/pages/authentication-authorization/manage-roles.adoc

@@ -339,7 +339,9 @@ For more information, see xref:authentication-authorization/dbms-administration.
 == Listing roles
 
 
-You can view all available roles using the Cypher command `SHOW ROLES`, which returns a single column by default. You can optionally use `SHOW ROLES YIELD *` to return the `IMMUTABLE` column. (See xref:authentication-authorization/manage-roles.adoc#access-control-immutable-roles[immutable roles] for more information).
+You can view all available roles using the Cypher command `SHOW ROLES`, which returns a single column by default.
+You can optionally use `SHOW ROLES YIELD *` to return the `immutable` column.
+(See xref:authentication-authorization/manage-roles.adoc#access-control-immutable-roles[immutable roles] for more information).
 
 .`SHOW ROLES` output
 [options="header", width="100%", cols="2a,4,2m"]
@@ -582,7 +584,9 @@ This is equivalent to running `DROP ROLE myrole IF EXISTS` followed by `CREATE R
 
 [[access-control-immutable-roles]]
 === Immutable roles
-Immutable roles are roles which cannot be modified in the usual way after they have been created. This means they cannot be renamed, dropped, or have privileges granted to or revoked from them. See xref:authentication-authorization/privileges-and-roles-immutable.adoc[here] for details.
+Immutable roles are roles which cannot be modified in the usual way.
+This means they cannot be created, renamed, dropped, or have privileges granted to or revoked from them.
+See xref:authentication-authorization/privileges-and-roles-immutable.adoc[here] for details.
 
 They are useful in cases where you need a permanent built-in system role which cannot be modified even by users who have xref:authentication-authorization/dbms-administration.adoc#access-control-dbms-administration-role-management[ROLE MANAGEMENT privileges].
 

modules/ROOT/pages/authentication-authorization/privileges-and-roles-immutable.adoc

@@ -13,14 +13,14 @@ Immutable roles were introduced in Neo4j 5.24. Immutable privileges have been av
 == How to administer immutable privileges and roles
 
 Unlike regular privileges and roles, immutable privileges and roles cannot be administered by users with xref:authentication-authorization/dbms-administration.adoc#access-control-dbms-administration-privilege-management[PRIVILEGE MANAGEMENT] and xref:authentication-authorization/dbms-administration.adoc#access-control-dbms-administration-role-management[ROLE MANAGEMENT] privileges. 
-Instead, they can only be administered when auth is disabled -- that is, when the configuration setting <<config_dbms.security.auth_enabled,`dbms.security.auth_enabled`>> is set to `false`.
+Instead, they can only be administered when auth is disabled -- that is, when the configuration setting xref:configuration/configuration-settings.adoc#config_dbms.security.auth_enabled[`dbms.security.auth_enabled`] is set to `false`.
 
 [CAUTION]
 Immutable privileges and roles should only be used in a scenario where changes are rare. 
 They are intentionally difficult to change and thus changes should be undertaken with caution (i.e. when the DBMS has been isolated by some other means and unauthorized access can be reliably prevented).
 It is considered to be the kind of action which may be performed once during the commissioning phase of a DBMS.
 
-When the configuration setting <<config_dbms.security.auth_enabled,`dbms.security.auth_enabled`>> is set to `false`, immutable privileges and roles can be administered in a similar way to regular privileges and roles, using the `IMMUTABLE` keyword.
+When the configuration setting xref:configuration/configuration-settings.adoc#config_dbms.security.auth_enabled[`dbms.security.auth_enabled`] is set to `false`, immutable privileges and roles can be administered in a similar way to regular privileges and roles, using the `IMMUTABLE` keyword.
 
 Once the dbms is safely isolated from external connections, follow these steps to administer immutable privileges and roles: