Index: main/waeup.kofa/trunk/docs/source/userdocs/students/browser.rst
===================================================================
--- main/waeup.kofa/trunk/docs/source/userdocs/students/browser.rst	(revision 14548)
+++ main/waeup.kofa/trunk/docs/source/userdocs/students/browser.rst	(revision 14574)
@@ -238,11 +238,11 @@
     `automatic` is set to ``True`` and `carry_over` to ``False.``
 
-2.  The portal can be configured
-    (`IConfigurationContainer.carry_over`) 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``.
+2. The portal can be configured
+   (`IConfigurationContainer.carry_over`) 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
@@ -251,8 +251,19 @@
 further courses, which they desire to attend, and can create
 additional course tickets, as long as the total number of 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).
+not exceed 50 (value customizable). 
+
+In most cases such an automatically created course list is not
+perfect or even ready for submission to the course adviser. The list
+must 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 the total number of credits of
+non-outstanding courses (if `outstanding` attribute is ``True``) do
+not exceed 50 (value customizable). That means outstanding courses
+are not considered as registered courses. Usually they are being
+added by officers.
+
+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
@@ -268,8 +279,8 @@
 they can validate or reject it by pressing the same-named link
 buttons. After pressing the 'Reject courses' button, Kofa redirects
-to the `ContactStudentFormPage` 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.
+to the `ContactStudentFormPage` 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.
 
 .. seealso::
@@ -296,5 +307,13 @@
 :py:meth:`CourseTicket.editable_by_lecturer<waeup.kofa.students.studylevel.CourseTicket.editable_by_lecturer>`.
 
-There are two options to edit course results. (1) Scores in course tickets can be changed by editing its values in the table and pressing the 'Update scores from table' button below. Scores can be cleared by removing the respective values. Lecturers have to be online during this process.(2) Alternatively, lecturers can download a csv file, edit scores in this csv file offline and upload the same file when they are online again. This procedure is explained in step-by-step instructions which show up when pressing the yellow 'Help' button:
+There are two options to edit course results. (1) Scores in course
+tickets can be changed by editing its values in the table and
+pressing the 'Update scores from table' button below. Scores can be
+cleared by removing the respective values. Lecturers have to be
+online during this process.(2) Alternatively, lecturers can download
+a csv file, edit scores in this csv file offline and upload the same
+file when they are online again. This procedure is explained in
+step-by-step instructions which show up when pressing the yellow
+'Help' button:
 
 .. admonition:: Help
@@ -303,11 +322,18 @@
 
   1. Download csv file.
-  2. Open csv file in a text editor or in a spreadsheet programme (Excel or Calc).
-  3. Edit course results only. Do not modify other entries. Do not remove or add columns. Do not add rows.
-  4. Save file in same format (csv). Do not switch to any other format (xls, xlsx or ods).
-  5. Select same file for upload and press the blue 'Update ...' button.
-  6. The values in the table will be updated. Spot-check if the values in the table correspond with the values in your file.
-
-  Note: Only course results of students which are in state 'courses validated' and in current academic session can be modified. Additional data will just be ignored.
+  2. Open csv file in a text editor or in a spreadsheet programme
+     (Excel or Calc).
+  3. Edit course results only. Do not modify other entries.
+     Do not remove or add columns. Do not add rows.
+  4. Save file in same format (csv). Do not switch to any other
+     format (xls, xlsx or ods).
+  5. Select same file for upload and press the blue 'Update ...'
+     button.
+  6. The values in the table will be updated. Spot-check if the
+     values in the table correspond with the values in your file.
+
+  Note: Only course results of students which are in state
+  'courses validated' and in current academic session can be modified.
+  Additional data will just be ignored.
 
 .. seealso::
@@ -374,16 +400,17 @@
 ------------------
 
-Officers with `ManageHostels` permission do see a 'Relocate student' link
-button which calls the `BedTicketRelocationView`. This view relocates the
-student if student parameters or the bed type of the bed have changed. The
-`update` method of this view calls the
-:py:meth:`BedTicket.relocateStudent<waeup.kofa.students.accommodation.BedTicket.relocateStudent>`
-method which checks first, if the student has a 'reserved' bed space.
-Students in reserved beds are never subject to relocation. It checks secondly,
-if booking has been cancelled in the accommodation section but other bed space
-has been manually allocated after cancellation. Then this bed is used, no
-matter whether the bed meets the bed type criteria or not. If both checks are
-negative, Kofa searches for a free bed space, which meets the student's bed
-type criteria. Only if it finds a new and free bed space, it starts the
+Officers with `ManageHostels` permission do see a 'Relocate student'
+link button which calls the `BedTicketRelocationView`. This view
+relocates the student if student parameters or the bed type of the
+bed have changed. The `update` method of this view calls the
+:py:meth:`BedTicket.relocateStudent<waeup.kofa.students.accommodation.BedTicket.relocateStudent>
+` method which checks first, if the student has a 'reserved' bed
+space. Students in reserved beds are never subject to relocation. It
+checks secondly, if booking has been cancelled in the accommodation
+section but other bed space has been manually allocated after
+cancellation. Then this bed is used, no matter whether the bed meets
+the bed type criteria or not. If both checks are negative, Kofa
+searches for a free bed space, which meets the student's bed type
+criteria. Only if it finds a new and free bed space, it starts the
 relocation process by releasing the old bed, booking the new bed and
 designating the new bed in the bed ticket.
Index: main/waeup.kofa/trunk/docs/source/userdocs/students/interfaces.rst
===================================================================
--- main/waeup.kofa/trunk/docs/source/userdocs/students/interfaces.rst	(revision 14548)
+++ main/waeup.kofa/trunk/docs/source/userdocs/students/interfaces.rst	(revision 14574)
@@ -288,8 +288,8 @@
 The quite long list of schema fields pretends that form pages may
 provide these fields for editing. This is not the case. Except for
-`score`, all these fields are 'for display' only. They can neither
-be changed through the UI nor by batch processing (import). They are
-solely meant for backing up the orginal course data. See also
-:ref:`course_ticket_processor`.
+`score`, `mandatory` and `outstanding` all other fields are 'for
+display' only. They can neither be changed through the UI nor by
+batch processing (import). They are solely meant for backing up the
+orginal course data. See also :ref:`course_ticket_processor`.
 
 .. note::
