source: main/waeup.kofa/trunk/docs/source/userdocs/applicants/create_students.rst @ 17364

Last change on this file since 17364 was 14934, checked in by Henrik Bettermann, 7 years ago

Do no longer hide the 'Create students' buttons but switch the portal to
maintenance mode to ensure that nobody can enter the portal during
record creation except for user 'admin'. This guarantees that record
creation is only started once.

File size: 4.1 KB
Line 
1.. _creating_students:
2
3Single Record Creation vs. Mass Creation
4========================================
5
6As brought up in the :ref:`application_workflow` chapter, the final
7step of the application process is the creation of the student
8record on the basis of the application data. Only applicants in
9state ``admitted`` can be turned into students. This is possible at
10various application section levels:
11
121. Officers can create student records from single applicant
13   records. A link button appears on the display page of each admitted
14   applicant which directly triggers the creation process:
15
16  |create_student_button|
17
182. The `ApplicantsContainerManageFormPage` provides a form button
19   which allows to create student records from above selected
20   applicants (maximum of 10):
21
22  |create_selected_students_button|
23
24  Only admitted applicants will be processed. Other selected
25  applicants will be skipped without further notice.
26
273. Last but not least, the portal managers do see a link button:
28
29  |create_students_button|
30
31  on the `ApplicantsContainerPage` and on the `ApplicantsRootPage`
32  which creates student records from applicants inside a single
33  applicants container or even portal-wide respectively. A warning
34  message appears before the process is started. After start the
35  portal is immediately switched into maintenance mode to ensure that
36  nobody can enter the portal during record creation except for user
37  'admin'. Maintenance mode is switched off as soon as the process has
38  finished.
39
40.. note::
41
42  Batch creation of thousands or even tenthousands of student records
43  is very computation intensive and takes quite a long time, even with
44  powerful computers. Experience has shown that the portal must be
45  switched to maintenance mode (or even disconnected from the Internet)
46  in order to avoid database write conflict errors, which cannot be
47  resolved if also students access the portal. Usually conflict
48  errrors are not serious. Unresolved conflicts just lead to an error
49  message and the database remains unchanged. Unfortunataly, student
50  creation does not only alter the object database. As we will see
51  below, also folders and files in the filesystem are added. These
52  filesystem changes are not being reverted after unresolved conflicts,
53  a fact which can cause serious problems.
54
55
56The `createStudent` Method
57==========================
58
59The `Applicant.createStudent` method is called for each admitted
60applicant. The method performs a series of checks before it creates
61a new student record:
62
631. Is the applicant really in the correct state?
64
652. Has the registration number not been assigned to another student?
66
673. Is a certificate (`course_admitted`) provided?
68
694. Can all required student attributes be copied and set? The
70   following attributes are copied:
71
72   .. autoattribute:: waeup.kofa.applicants.applicant.Applicant.applicant_student_mapping
73      :noindex:
74
755. Can the application slip be created? Defective images may
76   cause the adapter method to raise an exception (``IOError``).
77
78If all these checks are passed, a new student record is created, a
79password is set, the transitions ``create`` and ``admit`` are fired
80and all student study course attributes are set. All this is done
81in one database transaction.
82
83Furthermore, `createStudent` also produces an application slip pdf
84file, creates a new folder for the student in the filesystem and
85copies the pdf file together with the passport jpeg image file into
86the newly created folder. The copied application slip ensures, that
87the original application data do not get lost, when the application
88section is being purged.
89
90As mentioned above, folder creation and file copying are not part of
91the transaction and are not being rolled back if the database
92transactions fails, for example due to write conflict errors.
93Therefore, batch student creation should only be performed if the
94portal is offline.
95
96
97.. |create_student_button| image:: ../images/create_student_button.png
98   :scale: 50 %
99
100.. |create_students_button| image:: ../images/create_students_button.png
101   :scale: 50 %
102
103.. |create_selected_students_button| image:: ../images/create_selected_students_button.png
104   :scale: 50 %
Note: See TracBrowser for help on using the repository browser.