Changeset 13101 for main/waeup.kofa/trunk/docs/source/userdocs/applicants/browser.rst

Timestamp:

25 Jun 2015, 17:55:31 (9 years ago)

Author:

Henrik Bettermann

Message:

More docs.

File:

• main/waeup.kofa/trunk/docs/source/userdocs/applicants/browser.rst (modified) (1 diff)

main/waeup.kofa/trunk/docs/source/userdocs/applicants/browser.rst

@@ -102 +102 @@
 ========================
 
+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 on
+  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 affect 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. This may 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
+  set offline.
+
+
+
+.. |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 %
+