[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 |
---|
[14683] | 20 | applicants (maximum of 10): |
---|
[13108] | 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 | |
---|
[14934] | 27 | 3. Last but not least, the portal managers do see a link button: |
---|
[13108] | 28 | |
---|
| 29 | |create_students_button| |
---|
| 30 | |
---|
| 31 | on the `ApplicantsContainerPage` and on the `ApplicantsRootPage` |
---|
| 32 | which creates student records from applicants inside a single |
---|
[14934] | 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. |
---|
[13108] | 39 | |
---|
[14934] | 40 | .. note:: |
---|
[13108] | 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 |
---|
[14934] | 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. |
---|
[13108] | 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 | |
---|
[13118] | 75 | 5. Can the application slip be created? Defective images may |
---|
[13108] | 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 |
---|
[13118] | 80 | and all student study course attributes are set. All this is done |
---|
| 81 | in one database transaction. |
---|
[13108] | 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 | |
---|
[13118] | 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. |
---|
[13108] | 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 % |
---|