Index: main/waeup.kofa/trunk/docs/source/userdocs/security.rst
===================================================================
--- main/waeup.kofa/trunk/docs/source/userdocs/security.rst	(revision 13042)
+++ main/waeup.kofa/trunk/docs/source/userdocs/security.rst	(revision 13045)
@@ -10,5 +10,5 @@
 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
+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
@@ -23,5 +23,5 @@
 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
+do everything with this permissions. 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.
Index: main/waeup.kofa/trunk/docs/source/userdocs/students/browser.rst
===================================================================
--- main/waeup.kofa/trunk/docs/source/userdocs/students/browser.rst	(revision 13042)
+++ main/waeup.kofa/trunk/docs/source/userdocs/students/browser.rst	(revision 13045)
@@ -67,5 +67,5 @@
 When a clearance officer clicks the 'Save comment and reject clearance now' button, the `reject` action method of the :py:class:`StudentRejectClearancePage<waeup.kofa.students.browser.StudentRejectClearancePage>` is called. This method first checks, in which workflow state the student is, and fires a transition accordingly. Then the comment, which should explain why the request was requested, is saved twice in the `officer_comment` attribute of the student and in ``students.log``. As soon as the `clear` transition (d) is effected, an event handler clears the attribute again. The logfile message is permanent and ensures that the original cause of rejection can always be reconstructed.
 
-Finally, the method redirects to the ContactStudentForm and prefills the HTML form with the comment previously saved. The clearance officer can leave the comment as it is, or can modify the text to give more information about the reason of rejection. This comment will then be sent to the student by email. This comnent is not saved, neither in the student object nor in the logfile.
+Finally, the method redirects to the ContactStudentForm and prefills the HTML form with the comment previously saved. The clearance officer can leave the comment as it is, or can modify the text to give more information about the reason of rejection. This comment will then be sent to the student by email. This comment is not saved, neither in the student object nor in the logfile.
 
 .. important::
@@ -101,6 +101,6 @@
 .. _payment_tickets:
 
-Payment Tickets
-===============
+Payments
+========
 
 The `PaymentsManageFormPage` is used by both students and students officers. The page tabulates existing payment tickets and allows to add or remove tickets. Officers can remove all payment tickets, students only those without a response code (`r_code`). Attention: Students can remove tickets without response code even if they have been marked paid.
@@ -121,7 +121,7 @@
 
 Directly after a student payment ticket has been paid - either by approval by an officer or by receiving a positive response from a payment gateway - the
-:py:meth:`redeemTicket<waeup.kofa.students.payments.StudentOnlinePayment.redeemTicket>` method is called. Depending on the category of the payment, usually an appropriate access or activation code is beeing created for the owner of the ticket. This code must be entered on certain form pages to activate a service or to access the next stage of the registration process. In other words, making a payment and redeeming a payment are two different steps. Successful payments do not automatically trigger any action in the portal but create a specifc access code which can be used to trigger access-code-related actions (see :ref:`accesscodes`).
+:py:meth:`redeemTicket<waeup.kofa.students.payments.StudentOnlinePayment.redeemTicket>` method is called. Depending on the category of the payment, an appropriate access or activation code is beeing created for the owner of the ticket. This code must be entered on certain form pages to activate the paid service or to access the next stage of the registration process. In other words, making a payment and redeeming a payment are two different steps. Successful payments do not automatically trigger any action in the portal but create a specifc access code which can be used to trigger access-code-related actions (see :ref:`accesscodes`).
 
-Until May 2015 also school fee payments had produced access codes which enabled students to start the next session. Meanwile, Kofa bypasses SFE access code creation if next session can be started directly.
+Until May 2015 also school fee payments had produced access codes, which enabled students to start the next session. Since software revision 12889, Kofa bypasses SFE access code creation and starts the next session automatically.
 
 Previous Session Payment Tickets
@@ -133,5 +133,24 @@
 -----------------------
 
-Balance payments have been introduced to correct previously made payments. In some cases students select the wrong payment category or other things may have happened which led students pay less than expected. This can be balanced by paying a differential amount. Therefore, the add form for balance payments allows to freely choose the amount to be paid. It also asks for the category, the session and the level the payment is meant for. Like previous session paymnets, balance payments do not induce further actions in Kofa. Both can be omitted in customized versions of Kofa.
+Balance payments have been introduced to correct previously made payments. In some cases, students select the wrong payment category, or other things may have happened which led students pay less than expected. This can be balanced by paying a differential amount. Therefore, the add form for balance payments allows to freely choose the total amount to be paid. It also asks for the category, the session and the level the payment is meant for. Like previous session payments, balance payments do not induce further actions in Kofa. Both can be omitted in customized versions of Kofa if these features are not needed.
+
+Course Registration
+===================
+
+Study levels are pre-filled with course tickets. When adding a study level, :py:meth:`StudentStudyCourse.addStudentStudyLevel<waeup.kofa.students.studycourse.StudentStudyCourse.addStudentStudyLevel>` automatically adds course tickets in two steps:
+
+1. :py:meth:`StudentStudyLevel.addCertCourseTickets<waeup.kofa.students.studylevel.StudentStudyLevel.addCertCourseTickets>` is called which iterates over the certificate courses of the certificate container object in the academic section and creates course tickets if the `level` attribute matches. `title`, `fcode`, `dcode`, `credits`, `passmark` and `semester` are copied from the course object which is attached to the certificate course; `mandatory` is taken from the certificate course itself. Finally, `automatic` is set to ``True`` and `carry_over` to ``False.``
+
+2. The portal can be configured such that failed courses are automatically carried over from one session to the next. Failed course tickets from the previous level, i.e. tickets with a score below the passmark, are collected and 'copied' into the current study level container. The attributes `automatic` and `carry_over` are set to ``True``.
+
+In most cases, such an automatically created course list is not perfect or even ready for submission to the course adviser. The list has to be edited according to the student's needs. Students can select further courses, which they desire to attend, and can create additional course tickets, as long as total credits do not exceed 50 (value customizable). Course tickets can also be removed. Whereas officers can remove any ticket from the list, students can remove only optional (non-mandatory) course tickets (condition customizable).
+
+The edit form page provides a 'Register course list' button which submits the course list to the course adviser for validation. Course advisers can't edit the registered/submitted course list, but they can validate or reject it by pressing the same-named link buttons. After pressing the 'Reject courses' button, Kofa redirects to the ContactStudentForm which can be used to inform the student about the reason of rejection. In contrast to clearance rejection, the message, which is being sent to the student by email, is neither stored in the database nor in the logfiles.
+
+Editing Scores by Lecturers
+===========================
+
+Requesting New Password
+=======================
 
 Bed Tickets
@@ -141,15 +160,5 @@
 --------------
 
-Course Tickets
-==============
 
-Course Registration
-===================
-
-Requesting a Password
-=====================
-
-Editing Scores by Lecturers
-===========================
 
 .. _bootstrap: http://getbootstrap.com/
