Ignore:
Timestamp:
26 Jun 2015, 14:42:37 (9 years ago)
Author:
Henrik Bettermann
Message:

Rename button.

Reorganize applicants section docs.

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r13104 r13108  
    9696manually.
    9797
    98 
    99 .. _creating_students:
    100 
    101 Creating Student Records
    102 ========================
    103 
    104 As brought up in the :ref:`application_workflow` chapter, the final
    105 step of the application process is the creation of the student
    106 record on the basis of the application data. Only applicants in
    107 state ``admitted`` can be turned into students. This is possible at
    108 various application section levels:
    109 
    110 1. 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 
    116 2. 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 
    125 3. 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 with
    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 alter 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, a fact which can cause serious
    147   problems.
    148 
    149   So the answer to the question is trivial: We expect that the admin
    150   user knows what s/he is doing and is careful enough to start the
    151   creation process in maintenance mode, which means when the portal is
    152   disconnected from a public network.
    153 
    154 
    155 
    156 .. |create_student_button| image:: create_student_button.png
    157    :scale: 50 %
    158 
    159 .. |create_students_button| image:: create_students_button.png
    160    :scale: 50 %
    161 
    162 .. |create_selected_students_button| image:: create_selected_students_button.png
    163    :scale: 50 %
    164 
    165 `Applicant.createStudent`
    166 -------------------------
    167 
    168 The `createStudent` method is called for each admitted applicant.
    169 The method performs a series of checks before it creates a new
    170 student record:
    171 
    172 1. Is the applicant really in the correct state?
    173 
    174 2. Has the registration number not been assigned to another student?
    175 
    176 3. Is a certificate (`course_admitted`) provided?
    177 
    178 4. Can all required student attributes be copied and set? The
    179    following attributes are copied:
    180 
    181    .. autoattribute:: waeup.kofa.applicants.applicant.Applicant.applicant_student_mapping
    182       :noindex:
    183 
    184 5. Can the application slip can be created? Defective images may
    185    cause the adapter method to raise an exception (``IOError``).
    186 
    187 If all these checks are passed, a new student record is created, a
    188 password is set, the transitions ``create`` and ``admit`` are fired
    189 and all student study course attributes are set. These are the
    190 changes which affect the database.
    191 
    192 Furthermore, `createStudent` also produces an application slip pdf
    193 file, creates a new folder for the student in the filesystem and
    194 copies the pdf file together with the passport jpeg image file into
    195 the newly created folder. The copied application slip ensures, that
    196 the original application data do not get lost, when the application
    197 section is being purged.
    198 
    199 As mentioned above, folder creation and file copying are not being
    200 rolled back if the database transactions fails, e.g. due to write
    201 conflict errors. Therefore, batch student creation should only be
    202 performed if the portal is offline.
Note: See TracChangeset for help on using the changeset viewer.