[13108] | 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 |
---|
[13273] | 14 | applicant which directly triggers the creation process: |
---|
[13108] | 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: |
---|
| 21 | |
---|
| 22 | |create_selected_students_button| |
---|
| 23 | |
---|
| 24 | Only admitted applicants will be processed. Other selected |
---|
[13273] | 25 | applicants will be skipped without further notice. |
---|
[13108] | 26 | |
---|
| 27 | 3. Last but not least, the portal manager with user id ``admin`` |
---|
[13273] | 28 | does see a link button: |
---|
[13108] | 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 | |
---|
[13118] | 76 | 5. Can the application slip be created? Defective images may |
---|
[13108] | 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 |
---|
[13118] | 81 | and all student study course attributes are set. All this is done |
---|
| 82 | in one database transaction. |
---|
[13108] | 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 | |
---|
[13118] | 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. |
---|
[13108] | 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 % |
---|