Access control documentation: Formatting
Add empty second line above some headlines for consistency
Change-Id: Ic31e0540376a17c0b78d3f40d0301d41645789c4
Signed-off-by: Fredrik Luthander <fredrik.luthander@sonymobile.com>
diff --git a/Documentation/access-control.txt b/Documentation/access-control.txt
index 44198e8..558b784 100644
--- a/Documentation/access-control.txt
+++ b/Documentation/access-control.txt
@@ -15,6 +15,7 @@
in the `system_config` table within the database, so the groups
can be renamed after installation if desired.
+
[[administrators]]
Administrators
~~~~~~~~~~~~~~
@@ -33,6 +34,7 @@
to permit administrative users to otherwise access Gerrit as any
other normal user would, without needing two different accounts.
+
[[anonymous_users]]
Anonymous Users
~~~~~~~~~~~~~~~
@@ -48,6 +50,7 @@
to grant `Read` access to this group as Gerrit requires an account
identity for all other operations.
+
[[non-interactive_users]]
Non-Interactive Users
~~~~~~~~~~~~~~~~~~~~~
@@ -63,6 +66,7 @@
users. This ensures that the interactive users can keep working when
resources are tight.
+
[[project_owners]]
Project Owners
~~~~~~~~~~~~~~
@@ -80,6 +84,7 @@
avoid the need to initially configure access rights for
newly created child projects.
+
[[registered_users]]
Registered Users
~~~~~~~~~~~~~~~~
@@ -134,6 +139,7 @@
members of `Foo` have submit rights on a project, and the members of
`Foo-admin` typically do not need to have such rights.
+
[[ldap_groups]]
LDAP Groups
-----------
@@ -255,6 +261,7 @@
|Foo Leads |refs/heads/qa |Code-Review| -2..+2 |
|==============================================================
+
OpenID Authentication
~~~~~~~~~~~~~~~~~~~~~
@@ -264,6 +271,7 @@
of its OpenID identities match one or more of the patterns listed
in the `auth.trustedOpenID` list from `gerrit.config`.
+
All Projects
~~~~~~~~~~~~
@@ -283,6 +291,7 @@
`Administrators` does, as group members would be able to alter
permissions for every managed project including global capabilities.
+
Per-Project
~~~~~~~~~~~
@@ -406,6 +415,7 @@
<<conversion_table,table>> to better understand the access rights
conversions from the Gerrit 2.1.x to the Gerrit 2.2.x series.
+
[[category_abandon]]
Abandon
~~~~~~~
@@ -417,6 +427,7 @@
This also grants the permission to restore a change if the change
can be uploaded.
+
[[category_create]]
Create reference
~~~~~~~~~~~~~~~~
@@ -609,6 +620,7 @@
the intention of the `Push Merge Commit` entry is to allow direct pushes
of merge commits.
+
[[category_push_annotated]]
Push Annotated Tag
~~~~~~~~~~~~~~~~~~
@@ -718,6 +730,7 @@
can still do the rebase locally and upload the rebased commit as a new
patch set.
+
[[category_remove_reviewer]]
Remove Reviewer
~~~~~~~~~~~~~~~
@@ -817,6 +830,7 @@
general guidelines for a typical way to set up your project on a
brand new Gerrit instance.
+
[[examples_contributor]]
Contributor
~~~~~~~~~~~
@@ -960,6 +974,7 @@
* <<category_owner,`Owner`>> in the gits they mostly work with.
+
[[examples_administrator]]
Administrator
~~~~~~~~~~~~~
@@ -977,6 +992,7 @@
* <<examples_project-owner,Project owner rights>>
+
Enforcing site wide access policies
-----------------------------------
@@ -1001,6 +1017,7 @@
* Project owners can manage access rights of their projects without a danger
of violating a site wide policy
+
[[block]]
'BLOCK' access rule
~~~~~~~~~~~~~~~~~~~
@@ -1049,6 +1066,7 @@
different access section of the same project or in any access section in an
inheriting project cannot override a 'BLOCK' rule.
+
Examples
~~~~~~~~
@@ -1078,6 +1096,7 @@
pushTag = group Project Owners
====
+
Let only a dedicated group vote in a special category
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -1095,6 +1114,7 @@
label-Release-Proces = -1..+1 group Release Engineers
====
+
[[conversion_table]]
Conversion table from 2.1.x series to 2.2.x series
--------------------------------------------------
@@ -1190,6 +1210,7 @@
either link:cmd-create-project.html[create new git projects via ssh]
or via the web UI.
+
[[capability_emailReviewers]]
Email Reviewers
~~~~~~~~~~~~~~~
@@ -1200,6 +1221,7 @@
emailed. The allow rules are evaluated before deny rules, however the default
is to allow emailing, if no explicit rule is matched.
+
[[capability_flushCaches]]
Flush Caches
~~~~~~~~~~~~
