Ignore:
Timestamp:
25 Jun 2015, 17:55:31 (9 years ago)
Author:
Henrik Bettermann
Message:

More docs.

Location:
main/waeup.kofa/trunk/docs/source/userdocs/applicants
Files:
3 added
1 edited

Legend:

Unmodified
Added
Removed
  • main/waeup.kofa/trunk/docs/source/userdocs/applicants/browser.rst

    r13100 r13101  
    102102========================
    103103
     104As brought up in the :ref:`application_workflow` chapter, the final
     105step of the application process is the creation of the student
     106record on the basis of the application data. Only applicants in
     107state ``admitted`` can be turned into students. This is possible at
     108various application section levels:
     109
     1101. Officers can create student records from single applicant
     111   records. A link button appears on the display page of each admitted
     112   applicants which directly triggers the creation process:
     113
     114  |create_student_button|
     115
     1162. The `ApplicantsContainerManageFormPage` provides a form button
     117   which allows to create student records from above selected
     118   applicants:
     119
     120  |create_selected_students_button|
     121
     122  Only admitted applicants will be processed. Other selected
     123  applicants will be skipped without further notice
     124
     1253. Last but not least, the portal manager with user id ``admin``
     126   does see a link buttons:
     127
     128  |create_students_button|
     129
     130  on the `ApplicantsContainerPage` and on the `ApplicantsRootPage`
     131  which creates student records from applicants inside a single
     132  applicants container or even portal-wide respectively.
     133
     134  The reader may wonder: Why only user ``admin``?
     135
     136  Batch creation of thousands or even tenthousands of student records
     137  is very computation intensive and takes quite a long time, even on
     138  powerful computers. Experience has shown that the portal must be
     139  disconnected from the Internet in order to avoid database write
     140  conflict errors, which cannot be resolved if also students access
     141  the portal. Usually conflict errrors are not serious. Unresolved
     142  conflicts just lead to an error message and the database remains
     143  unchanged. Unfortunataly, student creation does not only affect the
     144  object database. As we will see below, also folders and files in the
     145  filesystem are added. These filesystem changes are not being
     146  reverted after unresolved conflicts. This may cause serious problems.
     147
     148  So the answer to the question is trivial: We expect that the admin
     149  user knows what s/he is doing and is careful enough to start the
     150  creation process in maintenance mode, which means when the portal is
     151  set offline.
     152
     153
     154
     155.. |create_student_button| image:: create_student_button.png
     156   :scale: 50 %
     157
     158.. |create_students_button| image:: create_students_button.png
     159   :scale: 50 %
     160
     161.. |create_selected_students_button| image:: create_selected_students_button.png
     162   :scale: 50 %
     163
Note: See TracChangeset for help on using the changeset viewer.