Index: main/waeup.kofa/trunk/docs/source/userdocs/applicants.rst
===================================================================
--- main/waeup.kofa/trunk/docs/source/userdocs/applicants.rst	(revision 13107)
+++ main/waeup.kofa/trunk/docs/source/userdocs/applicants.rst	(revision 13108)
@@ -84,3 +84,10 @@
 
 
+Student Record Creation
+=======================
 
+.. toctree::
+   :maxdepth: 3
+
+   applicants/create_students
+
Index: main/waeup.kofa/trunk/docs/source/userdocs/applicants/browser.rst
===================================================================
--- main/waeup.kofa/trunk/docs/source/userdocs/applicants/browser.rst	(revision 13107)
+++ main/waeup.kofa/trunk/docs/source/userdocs/applicants/browser.rst	(revision 13108)
@@ -96,107 +96,2 @@
 manually.
 
-
-.. _creating_students:
-
-Creating Student Records
-========================
-
-As brought up in the :ref:`application_workflow` chapter, the final
-step of the application process is the creation of the student
-record on the basis of the application data. Only applicants in
-state ``admitted`` can be turned into students. This is possible at
-various application section levels:
-
-1. Officers can create student records from single applicant
-   records. A link button appears on the display page of each admitted
-   applicants which directly triggers the creation process:
-
-  |create_student_button|
-
-2. The `ApplicantsContainerManageFormPage` provides a form button
-   which allows to create student records from above selected
-   applicants:
-
-  |create_selected_students_button|
-
-  Only admitted applicants will be processed. Other selected
-  applicants will be skipped without further notice
-
-3. Last but not least, the portal manager with user id ``admin``
-   does see a link buttons:
-
-  |create_students_button|
-
-  on the `ApplicantsContainerPage` and on the `ApplicantsRootPage`
-  which creates student records from applicants inside a single
-  applicants container or even portal-wide respectively.
-
-  The reader may wonder: Why only user ``admin``?
-
-  Batch creation of thousands or even tenthousands of student records
-  is very computation intensive and takes quite a long time, even with
-  powerful computers. Experience has shown that the portal must be
-  disconnected from the Internet in order to avoid database write
-  conflict errors, which cannot be resolved if also students access
-  the portal. Usually conflict errrors are not serious. Unresolved
-  conflicts just lead to an error message and the database remains
-  unchanged. Unfortunataly, student creation does not only alter the
-  object database. As we will see below, also folders and files in the
-  filesystem are added. These filesystem changes are not being
-  reverted after unresolved conflicts, a fact which can cause serious
-  problems.
-
-  So the answer to the question is trivial: We expect that the admin
-  user knows what s/he is doing and is careful enough to start the
-  creation process in maintenance mode, which means when the portal is
-  disconnected from a public network.
-
-
-
-.. |create_student_button| image:: create_student_button.png
-   :scale: 50 %
-
-.. |create_students_button| image:: create_students_button.png
-   :scale: 50 %
-
-.. |create_selected_students_button| image:: create_selected_students_button.png
-   :scale: 50 %
-
-`Applicant.createStudent`
--------------------------
-
-The `createStudent` method is called for each admitted applicant.
-The method performs a series of checks before it creates a new
-student record:
-
-1. Is the applicant really in the correct state?
-
-2. Has the registration number not been assigned to another student?
-
-3. Is a certificate (`course_admitted`) provided?
-
-4. Can all required student attributes be copied and set? The
-   following attributes are copied:
-
-   .. autoattribute:: waeup.kofa.applicants.applicant.Applicant.applicant_student_mapping
-      :noindex:
-
-5. Can the application slip can be created? Defective images may
-   cause the adapter method to raise an exception (``IOError``).
-
-If all these checks are passed, a new student record is created, a
-password is set, the transitions ``create`` and ``admit`` are fired
-and all student study course attributes are set. These are the
-changes which affect the database.
-
-Furthermore, `createStudent` also produces an application slip pdf
-file, creates a new folder for the student in the filesystem and
-copies the pdf file together with the passport jpeg image file into
-the newly created folder. The copied application slip ensures, that
-the original application data do not get lost, when the application
-section is being purged.
-
-As mentioned above, folder creation and file copying are not being
-rolled back if the database transactions fails, e.g. due to write
-conflict errors. Therefore, batch student creation should only be
-performed if the portal is offline.
Index: main/waeup.kofa/trunk/docs/source/userdocs/applicants/create_students.rst
===================================================================
--- main/waeup.kofa/trunk/docs/source/userdocs/applicants/create_students.rst	(revision 13108)
+++ main/waeup.kofa/trunk/docs/source/userdocs/applicants/create_students.rst	(revision 13108)
@@ -0,0 +1,104 @@
+.. _creating_students:
+
+Single Record Creation vs. Mass Creation
+========================================
+
+As brought up in the :ref:`application_workflow` chapter, the final
+step of the application process is the creation of the student
+record on the basis of the application data. Only applicants in
+state ``admitted`` can be turned into students. This is possible at
+various application section levels:
+
+1. Officers can create student records from single applicant
+   records. A link button appears on the display page of each admitted
+   applicants which directly triggers the creation process:
+
+  |create_student_button|
+
+2. The `ApplicantsContainerManageFormPage` provides a form button
+   which allows to create student records from above selected
+   applicants:
+
+  |create_selected_students_button|
+
+  Only admitted applicants will be processed. Other selected
+  applicants will be skipped without further notice
+
+3. Last but not least, the portal manager with user id ``admin``
+   does see a link buttons:
+
+  |create_students_button|
+
+  on the `ApplicantsContainerPage` and on the `ApplicantsRootPage`
+  which creates student records from applicants inside a single
+  applicants container or even portal-wide respectively.
+
+  The reader may wonder: Why only user ``admin``?
+
+  Batch creation of thousands or even tenthousands of student records
+  is very computation intensive and takes quite a long time, even with
+  powerful computers. Experience has shown that the portal must be
+  disconnected from the Internet in order to avoid database write
+  conflict errors, which cannot be resolved if also students access
+  the portal. Usually conflict errrors are not serious. Unresolved
+  conflicts just lead to an error message and the database remains
+  unchanged. Unfortunataly, student creation does not only alter the
+  object database. As we will see below, also folders and files in the
+  filesystem are added. These filesystem changes are not being
+  reverted after unresolved conflicts, a fact which can cause serious
+  problems.
+
+  So the answer to the question is trivial: We expect that the admin
+  user knows what s/he is doing and is careful enough to start the
+  creation process in maintenance mode, which means when the portal is
+  disconnected from a public network.
+
+
+The `createStudent` Method
+==========================
+
+The `Applicant.createStudent` method is called for each admitted
+applicant. The method performs a series of checks before it creates
+a new student record:
+
+1. Is the applicant really in the correct state?
+
+2. Has the registration number not been assigned to another student?
+
+3. Is a certificate (`course_admitted`) provided?
+
+4. Can all required student attributes be copied and set? The
+   following attributes are copied:
+
+   .. autoattribute:: waeup.kofa.applicants.applicant.Applicant.applicant_student_mapping
+      :noindex:
+
+5. Can the application slip can be created? Defective images may
+   cause the adapter method to raise an exception (``IOError``).
+
+If all these checks are passed, a new student record is created, a
+password is set, the transitions ``create`` and ``admit`` are fired
+and all student study course attributes are set. These are the
+changes which affect the database.
+
+Furthermore, `createStudent` also produces an application slip pdf
+file, creates a new folder for the student in the filesystem and
+copies the pdf file together with the passport jpeg image file into
+the newly created folder. The copied application slip ensures, that
+the original application data do not get lost, when the application
+section is being purged.
+
+As mentioned above, folder creation and file copying are not being
+rolled back if the database transactions fails, e.g. due to write
+conflict errors. Therefore, batch student creation should only be
+performed if the portal is offline.
+
+
+.. |create_student_button| image:: ../images/create_student_button.png
+   :scale: 50 %
+
+.. |create_students_button| image:: ../images/create_students_button.png
+   :scale: 50 %
+
+.. |create_selected_students_button| image:: ../images/create_selected_students_button.png
+   :scale: 50 %
Index: main/waeup.kofa/trunk/docs/source/userdocs/browsing.rst
===================================================================
--- main/waeup.kofa/trunk/docs/source/userdocs/browsing.rst	(revision 13107)
+++ main/waeup.kofa/trunk/docs/source/userdocs/browsing.rst	(revision 13108)
@@ -34,13 +34,13 @@
 The navigation bar for an anonymous user:
 
-.. image:: navbar_anon.png
+.. image:: images/navbar_anon.png
 
 The navigation bar for a student with drop-down menue:
 
-.. image:: navbar_student.png
+.. image:: images/navbar_student.png
 
 The navigation bar for an officer with lots of permissions:
 
-.. image:: navbar_officer.png
+.. image:: images/navbar_officer.png
 
 Officers see a double-column theme after logging in. The left column
@@ -54,5 +54,5 @@
 pages of an applicant or student record respectively.
 
-.. image:: multicolumn.png
+.. image:: images/multicolumn.png
 
 
@@ -135,5 +135,5 @@
 page and are sending GET requests to open the page. Example:
 
-.. image:: link_button.png
+.. image:: images/link_button.png
    :scale: 50 %
 
@@ -144,5 +144,5 @@
 another Kofa page. Example:
 
-.. image:: form_buttons.png
+.. image:: images/form_buttons.png
    :scale: 50 %
 
Index: main/waeup.kofa/trunk/docs/source/userdocs/users.rst
===================================================================
--- main/waeup.kofa/trunk/docs/source/userdocs/users.rst	(revision 13107)
+++ main/waeup.kofa/trunk/docs/source/userdocs/users.rst	(revision 13108)
@@ -86,5 +86,5 @@
 to manage the database and also access the Kofa user interface.
 
-.. image:: Grok_UI.png
+.. image:: images/Grok_UI.png
 
 Although the manager automatically gains all permissions the system
Index: main/waeup.kofa/trunk/src/waeup/kofa/applicants/viewlets.py
===================================================================
--- main/waeup.kofa/trunk/src/waeup/kofa/applicants/viewlets.py	(revision 13107)
+++ main/waeup.kofa/trunk/src/waeup/kofa/applicants/viewlets.py	(revision 13108)
@@ -236,5 +236,5 @@
     grok.require('waeup.manageApplication')
     icon = 'actionicon_entrance.png'
-    text = _('Create student record')
+    text = _('Create student')
     target ='createstudent'
 
Index: main/waeup.kofa/trunk/src/waeup/kofa/applicants/workflow.py
===================================================================
--- main/waeup.kofa/trunk/src/waeup/kofa/applicants/workflow.py	(revision 13107)
+++ main/waeup.kofa/trunk/src/waeup/kofa/applicants/workflow.py	(revision 13108)
@@ -106,5 +106,5 @@
     Transition(
         transition_id = 'create',
-        title = _('Create student record'),
+        title = _('Create student'),
         msg = _('Student record created'),
         source = ADMITTED,
Index: main/waeup.kofa/trunk/src/waeup/kofa/students/browser.py
===================================================================
--- main/waeup.kofa/trunk/src/waeup/kofa/students/browser.py	(revision 13107)
+++ main/waeup.kofa/trunk/src/waeup/kofa/students/browser.py	(revision 13108)
@@ -349,5 +349,5 @@
     pnav = 4
 
-    @action(_('Create student record'), style='primary')
+    @action(_('Create student'), style='primary')
     def addStudent(self, **data):
         student = createObject(u'waeup.Student')
Index: main/waeup.kofa/trunk/src/waeup/kofa/students/tests/test_browser.py
===================================================================
--- main/waeup.kofa/trunk/src/waeup/kofa/students/tests/test_browser.py	(revision 13107)
+++ main/waeup.kofa/trunk/src/waeup/kofa/students/tests/test_browser.py	(revision 13108)
@@ -274,9 +274,9 @@
         self.browser.getControl(name="form.lastname").value = 'Tester'
         self.browser.getControl(name="form.reg_number").value = '123'
-        self.browser.getControl("Create student record").click()
+        self.browser.getControl("Create student").click()
         self.assertTrue('Registration number exists already'
             in self.browser.contents)
         self.browser.getControl(name="form.reg_number").value = '1234'
-        self.browser.getControl("Create student record").click()
+        self.browser.getControl("Create student").click()
         self.assertTrue('Student record created' in self.browser.contents)
 
