Index: main/waeup.kofa/trunk/docs/source/userdocs/security.rst
===================================================================
--- main/waeup.kofa/trunk/docs/source/userdocs/security.rst	(revision 12847)
+++ main/waeup.kofa/trunk/docs/source/userdocs/security.rst	(revision 12849)
@@ -4,7 +4,22 @@
 ********
 
-Kofa has a very efficient security machinery. The machinery does not perform authorization checks on the content objects themselves stored in the database but restricts the usage of views, i.e. web pages and forms which are needed to view or edit data. Views are protected by permissions the user must have to use the view. Instead of assigning permissions seperately to users, permissions are bundled into sets of permissions, so-called roles which can be assigned to users through the web interface.
-
-It is important to note that permissions do not include other permissions. Only roles 'include' permissions. A 'manage' permission, for example, does not automatically enable users to open pages which merely display the data. These pages have their own 'view' permission. Another example is the ManagePortal permission described below. The name of the permission may lead to believe that users can do everything with this permssions. This is not true. It does only give access to certain pages which are dedicated to portal managers and must not be accessed by any other user.
+Kofa has a very efficient security machinery. The machinery does not
+perform authorization checks on the content objects themselves stored
+in the database but restricts the usage of views, i.e. web pages and
+forms which are needed to view or edit data. Views are protected by
+permissions the user must have to use the view. Instead of assigning
+permissions seperately to users, permissions are bundled into sets of
+permissions, so-called roles which can be assigned to users through
+the web interface.
+
+It is important to note that permissions do not include other
+permissions. Only roles 'include' permissions. A 'manage' permission,
+for example, does not automatically enable users to open pages which
+merely display the data. These pages have their own 'view'
+permission. Another example is the ManagePortal permission described
+below. The name of the permission may lead to believe that users can
+do everything with this permssions. This is not true. It does only
+give access to certain pages which are dedicated to portal managers
+and must not be accessed by any other user.
 
 .. contents::
@@ -13,5 +28,8 @@
 ===========
 
-The whole set of permission and role classes are described in the :py:mod:`Permissions and Roles Module<waeup.kofa.permissions>`. Here we describe only a subset of permission classes which are essential for the security settings configuration.
+The whole set of permission and role classes are described in the
+:py:mod:`Permissions and Roles Module<waeup.kofa.permissions>`. Here
+we describe only a subset of permission classes which are essential
+for the security settings configuration.
 
 General Permissions
@@ -126,7 +144,9 @@
 ============
 
-Global or site roles are assigned portal-wide. In contrast to local roles, users have this role in every context.
-
-Many global roles do only bundle one or two permissions. The objective behind is to share responsibilities and distribute tasks.
+Global or site roles are assigned portal-wide. In contrast to local
+roles, users have this role in every context.
+
+Many global roles do only bundle one or two permissions. The objective
+behind is to share responsibilities and distribute tasks.
 
 Global roles are being assigned via the user manage form page.
@@ -162,5 +182,6 @@
    :noindex:
 
-In contrast to these specialized sets of permissions, there are two sets which delegate extensive powers on portal managers. 
+In contrast to these specialized sets of permissions, there are two
+sets which delegate extensive powers on portal managers.
 
 .. autoclass:: waeup.kofa.permissions.PortalManager()
@@ -173,5 +194,6 @@
 --------------------------------
 
-Global Application Section Roles are assigned portal-wide (globally) but do actually only allocate permissions in the Application Section.
+Global Application Section Roles are assigned portal-wide (globally)
+but do actually only allocate permissions in the Application Section.
 
 .. autoclass:: waeup.kofa.applicants.permissions.ApplicantRole()
@@ -187,5 +209,6 @@
 ----------------------------
 
-Global Student Section Roles are assigned portal-wide (globally) but do actually only allocate permissions in the Student Section.
+Global Student Section Roles are assigned portal-wide (globally) but
+do actually only allocate permissions in the Student Section.
 
 .. autoclass:: waeup.kofa.students.permissions.StudentRole()
@@ -210,9 +233,20 @@
 =======================================
 
-In contrast to global roles, which are assigned portal-wide, local role permissions are gained for a specific context.
-
-Some local roles serve a second purpose. At first glance it appears strange that some of these 'odd' roles do not give more permissions than the user already has due to other roles. Their real purpose is to delegate permissions to the students or application section. If a user has for example the LocalStudentsManager role described below at department level, s/he automatically gets the StudentsManager role for those students studying in this department. We call this a **dynamic role**. In contrast to static global or local roles, dynamic roles are not stored in the database, they are dynamically assigned.
-
-Local roles are assigned either automatically by the system during user object setup or manually through the web interface. The automatically assigned local roles are:
+In contrast to global roles, which are assigned portal-wide, local
+role permissions are gained for a specific context.
+
+Some local roles serve a second purpose. At first glance it appears
+strange that some of these 'odd' roles do not give more permissions
+than the user already has due to other roles. Their real purpose is to
+delegate permissions to the students or application section. If a user
+has for example the LocalStudentsManager role described below at
+department level, s/he automatically gets the StudentsManager role for
+those students studying in this department. We call this a **dynamic
+role**. In contrast to static global or local roles, dynamic roles are
+not stored in the database, they are dynamically assigned.
+
+Local roles are assigned either automatically by the system during
+user object setup or manually through the web interface. The
+automatically assigned local roles are:
 
 .. autoclass:: waeup.kofa.permissions.Owner()
@@ -239,5 +273,6 @@
    :noindex:
 
-The following local roles do also delegate permissions to the student section. In other words, dynamic roles are assigned.
+The following local roles do also delegate permissions to the student
+section. In other words, dynamic roles are assigned.
 
 .. autoclass:: waeup.kofa.permissions.ClearanceOfficer()
