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>

1 files changed, 22 insertions, 0 deletions

diff --git a/Documentation/access-control.txt b/Documentation/access-control.txt
index 44198e8e27..558b78493f 100644
--- a/Documentation/access-control.txt
+++ b/Documentation/access-control.txt
@@ -15,6 +15,7 @@ and membership management.  The identity of these groups is set
 in the `system_config` table within the database, so the groups
 can be renamed after installation if desired.
 
+
 [[administrators]]
 Administrators
 ~~~~~~~~~~~~~~
@@ -33,6 +34,7 @@ approval or submit rights in projects.  This is a feature designed
 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 @@ without requiring sign in first.  Currently it is only worthwhile
 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 @@ made by the non-interactive users from the ones made by the interactive
 users. This ensures that the interactive users can keep working when
 resources are tight.
 
+
 [[project_owners]]
 Project Owners
 ~~~~~~~~~~~~~~
@@ -80,6 +84,7 @@ project.  Having default access rights for
 avoid the need to initially configure access rights for
 newly created child projects.
 
+
 [[registered_users]]
 Registered Users
 ~~~~~~~~~~~~~~~~
@@ -134,6 +139,7 @@ This configuration can help prevent accidental submits when the
 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 @@ would be needed:
 |Foo Leads       |refs/heads/qa |Code-Review| -2..+2 |
 |==============================================================
 
+
 OpenID Authentication
 ~~~~~~~~~~~~~~~~~~~~~
 
@@ -264,6 +271,7 @@ the `Anonymous Users` and `Registered Users` groups, unless *all*
 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 @@ group gives nearly the same level of access as membership in
 `Administrators` does, as group members would be able to alter
 permissions for every managed project including global capabilities.
 
+
 Per-Project
 ~~~~~~~~~~~
 
@@ -406,6 +415,7 @@ configuration was rewritten from scratch.  Use this
 <<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 @@ change to a given ref.
 This also grants the permission to restore a change if the change
 can be uploaded.
 
+
 [[category_create]]
 Create reference
 ~~~~~~~~~~~~~~~~
@@ -609,6 +620,7 @@ This applies even for an entry that complements a `Push` entry for
 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 @@ Users without this access right who are able to upload new patch sets
 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 @@ rights these roles typically should be granted. You may see them as
 general guidelines for a typical way to set up your project on a
 brand new Gerrit instance.
 
+
 [[examples_contributor]]
 Contributor
 ~~~~~~~~~~~
@@ -960,6 +974,7 @@ Optional access right to grant:
 
 * <<category_owner,`Owner`>> in the gits they mostly work with.
 
+
 [[examples_administrator]]
 Administrator
 ~~~~~~~~~~~~~
@@ -977,6 +992,7 @@ Suggested access rights to grant:
 
 * <<examples_project-owner,Project owner rights>>
 
+
 Enforcing site wide access policies
 -----------------------------------
 
@@ -1001,6 +1017,7 @@ non-blocked rules as they wish. This gives best of both worlds:
 * 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 @@ inside the same access section of the same project. An 'ALLOW' rule in a
 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 @@ owners>> are allowed to create tags, we would extend the example above:
     pushTag = group Project Owners
 ====
 
+
 Let only a dedicated group vote in a special category
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -1095,6 +1114,7 @@ category. In the "`All-Projects`" we define the following rules:
     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 @@ Allow project creation.  This capability allows the granted group to
 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 @@ Instead, only the authors of the change and those who starred it will be
 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
 ~~~~~~~~~~~~