Move security to top of TOC (#3439)

Author: dabrt

docs/infrastructure_and_maintenance/security/security_checklist.md

@@ -14,7 +14,7 @@ When getting ready to go live with your project for the first time, or when re-l
 
 ### Carefully select admin users
 
-Make sure Admin users and other privileged users who have access to System Information and setup in the back end are vetted and fully trustworthy.
+Make sure [Admin users](permission_use_cases.md#admin) and other privileged users who have access to System Information and setup in the back end are vetted and fully trustworthy.
 
 As administrator, you have access to full information about the system through the `setup/system_info` policy, and also to user data, role editing, and many other critical aspects.
 
@@ -38,7 +38,7 @@ This is specially important for admin accounts and other privileged users.
 
 ### Use secure roles and policies
 
-Use the following checklist to ensure the roles and policies are secure:
+Use the following checklist to ensure the [roles and policies](permission_overview.md) are secure:
 
 - Do roles restrict read/write access to content as they should? Is read/write access to personal data, like User content items, properly restricted?
 - Are the roles and their use properly differentiated and restricted? Is an editor role used for everyday editorial work?

docs/permissions/limitations.md

@@ -5,7 +5,7 @@ page_type: reference
 
 # Limitations
 
-Limitations are part of the permissions system.
+Limitations are part of the [permissions system](permissions.md).
 They limit the access granted to users by [policies](permission_overview.md).
 While a policy grants the user access to a function, Limitations narrow it down by different criteria.
 

docs/permissions/permission_overview.md

@@ -5,7 +5,7 @@ description: The permission system is based on policies that you assign to users
 # Permission overview
 
 A new user doesn't have permissions for any part of the system, unless they're explicitly given access.
-To get access they need to inherit roles, typically assigned to the user group they belong to.
+To get access they need to inherit **Roles**, typically assigned to the user group they belong to.
 
 Each role can contain one or more **Policies**.
 A policy is a rule that gives access to a single **function** in a **module**.
@@ -18,7 +18,7 @@ For example, a `content/publish` policy with a `ContentType` limitation on the "
 A limitation, like a policy, specifies what a user *can* do, not what they *can't do*.
 A `Section` limitation, for example, *gives* the user access to the selected section, not *prohibits* it.
 
-For more information, see [Limitation reference](limitation_reference.md) and [Permission use cases](permission_use_cases.md).
+For more information, see [Policies](policies.md), [Limitations reference](limitation_reference.md), and [Permission use cases](permission_use_cases.md).
 
 ## Assigning roles to users
 

docs/permissions/permission_use_cases.md

@@ -4,7 +4,7 @@ description: Set up permission sets for common use cases.
 
 # Permission use cases
 
-Here are a few examples of sets of policies that you can use to get some common permission configurations.
+Here are a few examples of sets of [policies](policies.md) that you can use to get some common [permission](permissions.md) configurations.
 
 ## Enter back office
 
@@ -51,7 +51,7 @@ To move a content item or a subtree to another location, the user must have the
 
 To send content to Trash, the user needs to have the `content/remove` policy.
 If content has more than one language, the user must have access to all the languages.
-That is, the `content/remove` policy must have either no limitation, or a limitation for all languages of the content item.
+That is, the `content/remove` policy must have either no [limitation](limitation_reference.md), or a limitation for all languages of the content item.
 
 To remove an archived version of content, the user must have the `content/versionremove` policy.
 

docs/permissions/permissions.md

@@ -10,6 +10,6 @@ The permission system of [[= product_name =]] enables you to control in detail w
 [[= cards([
     "permissions/permission_overview",
     "permissions/policies",
-    "permissions/permission_use_cases",
     "permissions/limitations",
+    "permissions/permission_use_cases",
 ], columns=4) =]]

docs/permissions/policies.md

@@ -6,8 +6,9 @@ month_change: false
 
 # Policies
 
-Policies are the main building block of the permissions system.
+Policies are the main building block of the [permissions system](permissions.md).
 Each role you assign to user or user group consists of policies which define, which parts of the application or website the user has access to.
+To limit access granted to users through policies, you can use [limitations](limitations.md).
 
 ## Available policies