| 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 manager with user id ``admin`` |
|---|
| 28 | does see a link button: |
|---|
| 29 | |
|---|
| 30 | |create_students_button| |
|---|
| 31 | |
|---|
| 32 | on the `ApplicantsContainerPage` and on the `ApplicantsRootPage` |
|---|
| 33 | which creates student records from applicants inside a single |
|---|
| 34 | applicants container or even portal-wide respectively. |
|---|
| 35 | |
|---|
| 36 | The reader may wonder: Why only user ``admin``? |
|---|
| 37 | |
|---|
| 38 | Batch creation of thousands or even tenthousands of student records |
|---|
| 39 | is very computation intensive and takes quite a long time, even with |
|---|
| 40 | powerful computers. Experience has shown that the portal must be |
|---|
| 41 | disconnected from the Internet in order to avoid database write |
|---|
| 42 | conflict errors, which cannot be resolved if also students access |
|---|
| 43 | the portal. Usually conflict errrors are not serious. Unresolved |
|---|
| 44 | conflicts just lead to an error message and the database remains |
|---|
| 45 | unchanged. Unfortunataly, student creation does not only alter the |
|---|
| 46 | object database. As we will see below, also folders and files in the |
|---|
| 47 | filesystem are added. These filesystem changes are not being |
|---|
| 48 | reverted after unresolved conflicts, a fact which can cause serious |
|---|
| 49 | problems. |
|---|
| 50 | |
|---|
| 51 | So the answer to the question is trivial: We expect that the admin |
|---|
| 52 | user knows what s/he is doing and is careful enough to start the |
|---|
| 53 | creation process in maintenance mode, which means when the portal is |
|---|
| 54 | disconnected from a public network. |
|---|
| 55 | |
|---|
| 56 | |
|---|
| 57 | The `createStudent` Method |
|---|
| 58 | ========================== |
|---|
| 59 | |
|---|
| 60 | The `Applicant.createStudent` method is called for each admitted |
|---|
| 61 | applicant. The method performs a series of checks before it creates |
|---|
| 62 | a new student record: |
|---|
| 63 | |
|---|
| 64 | 1. Is the applicant really in the correct state? |
|---|
| 65 | |
|---|
| 66 | 2. Has the registration number not been assigned to another student? |
|---|
| 67 | |
|---|
| 68 | 3. Is a certificate (`course_admitted`) provided? |
|---|
| 69 | |
|---|
| 70 | 4. Can all required student attributes be copied and set? The |
|---|
| 71 | following attributes are copied: |
|---|
| 72 | |
|---|
| 73 | .. autoattribute:: waeup.kofa.applicants.applicant.Applicant.applicant_student_mapping |
|---|
| 74 | :noindex: |
|---|
| 75 | |
|---|
| 76 | 5. Can the application slip be created? Defective images may |
|---|
| 77 | cause the adapter method to raise an exception (``IOError``). |
|---|
| 78 | |
|---|
| 79 | If all these checks are passed, a new student record is created, a |
|---|
| 80 | password is set, the transitions ``create`` and ``admit`` are fired |
|---|
| 81 | and all student study course attributes are set. All this is done |
|---|
| 82 | in one database transaction. |
|---|
| 83 | |
|---|
| 84 | Furthermore, `createStudent` also produces an application slip pdf |
|---|
| 85 | file, creates a new folder for the student in the filesystem and |
|---|
| 86 | copies the pdf file together with the passport jpeg image file into |
|---|
| 87 | the newly created folder. The copied application slip ensures, that |
|---|
| 88 | the original application data do not get lost, when the application |
|---|
| 89 | section is being purged. |
|---|
| 90 | |
|---|
| 91 | As mentioned above, folder creation and file copying are not part of |
|---|
| 92 | the transaction and are not being rolled back if the database |
|---|
| 93 | transactions fails, for example due to write conflict errors. |
|---|
| 94 | Therefore, batch student creation should only be performed if the |
|---|
| 95 | portal is offline. |
|---|
| 96 | |
|---|
| 97 | |
|---|
| 98 | .. |create_student_button| image:: ../images/create_student_button.png |
|---|
| 99 | :scale: 50 % |
|---|
| 100 | |
|---|
| 101 | .. |create_students_button| image:: ../images/create_students_button.png |
|---|
| 102 | :scale: 50 % |
|---|
| 103 | |
|---|
| 104 | .. |create_selected_students_button| image:: ../images/create_selected_students_button.png |
|---|
| 105 | :scale: 50 % |
|---|
