1 | .. _creating_students: |
---|
2 | |
---|
3 | Single Record Creation vs. Mass Creation |
---|
4 | ======================================== |
---|
5 | |
---|
6 | As brought up in the :ref:`application_workflow` chapter, the final |
---|
7 | step of the application process is the creation of the student |
---|
8 | record on the basis of the application data. Only applicants in |
---|
9 | state ``admitted`` can be turned into students. This is possible at |
---|
10 | various application section levels: |
---|
11 | |
---|
12 | 1. 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 | |
---|
18 | 2. 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 | |
---|
27 | 3. 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 | |
---|
56 | The `createStudent` Method |
---|
57 | ========================== |
---|
58 | |
---|
59 | The `Applicant.createStudent` method is called for each admitted |
---|
60 | applicant. The method performs a series of checks before it creates |
---|
61 | a new student record: |
---|
62 | |
---|
63 | 1. Is the applicant really in the correct state? |
---|
64 | |
---|
65 | 2. Has the registration number not been assigned to another student? |
---|
66 | |
---|
67 | 3. Is a certificate (`course_admitted`) provided? |
---|
68 | |
---|
69 | 4. 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 | |
---|
75 | 5. Can the application slip be created? Defective images may |
---|
76 | cause the adapter method to raise an exception (``IOError``). |
---|
77 | |
---|
78 | If all these checks are passed, a new student record is created, a |
---|
79 | password is set, the transitions ``create`` and ``admit`` are fired |
---|
80 | and all student study course attributes are set. All this is done |
---|
81 | in one database transaction. |
---|
82 | |
---|
83 | Furthermore, `createStudent` also produces an application slip pdf |
---|
84 | file, creates a new folder for the student in the filesystem and |
---|
85 | copies the pdf file together with the passport jpeg image file into |
---|
86 | the newly created folder. The copied application slip ensures, that |
---|
87 | the original application data do not get lost, when the application |
---|
88 | section is being purged. |
---|
89 | |
---|
90 | As mentioned above, folder creation and file copying are not part of |
---|
91 | the transaction and are not being rolled back if the database |
---|
92 | transactions fails, for example due to write conflict errors. |
---|
93 | Therefore, batch student creation should only be performed if the |
---|
94 | portal 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 % |
---|