Changeset 13101 for main/waeup.kofa/trunk/docs
- Timestamp:
- 25 Jun 2015, 17:55:31 (10 years ago)
- Location:
- main/waeup.kofa/trunk/docs/source/userdocs
- Files:
-
- 3 added
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
main/waeup.kofa/trunk/docs/source/userdocs/applicants/browser.rst
r13100 r13101 102 102 ======================== 103 103 104 As brought up in the :ref:`application_workflow` chapter, the final 105 step of the application process is the creation of the student 106 record on the basis of the application data. Only applicants in 107 state ``admitted`` can be turned into students. This is possible at 108 various application section levels: 109 110 1. Officers can create student records from single applicant 111 records. A link button appears on the display page of each admitted 112 applicants which directly triggers the creation process: 113 114 |create_student_button| 115 116 2. The `ApplicantsContainerManageFormPage` provides a form button 117 which allows to create student records from above selected 118 applicants: 119 120 |create_selected_students_button| 121 122 Only admitted applicants will be processed. Other selected 123 applicants will be skipped without further notice 124 125 3. Last but not least, the portal manager with user id ``admin`` 126 does see a link buttons: 127 128 |create_students_button| 129 130 on the `ApplicantsContainerPage` and on the `ApplicantsRootPage` 131 which creates student records from applicants inside a single 132 applicants container or even portal-wide respectively. 133 134 The reader may wonder: Why only user ``admin``? 135 136 Batch creation of thousands or even tenthousands of student records 137 is very computation intensive and takes quite a long time, even on 138 powerful computers. Experience has shown that the portal must be 139 disconnected from the Internet in order to avoid database write 140 conflict errors, which cannot be resolved if also students access 141 the portal. Usually conflict errrors are not serious. Unresolved 142 conflicts just lead to an error message and the database remains 143 unchanged. Unfortunataly, student creation does not only affect the 144 object database. As we will see below, also folders and files in the 145 filesystem are added. These filesystem changes are not being 146 reverted after unresolved conflicts. This may cause serious problems. 147 148 So the answer to the question is trivial: We expect that the admin 149 user knows what s/he is doing and is careful enough to start the 150 creation process in maintenance mode, which means when the portal is 151 set offline. 152 153 154 155 .. |create_student_button| image:: create_student_button.png 156 :scale: 50 % 157 158 .. |create_students_button| image:: create_students_button.png 159 :scale: 50 % 160 161 .. |create_selected_students_button| image:: create_selected_students_button.png 162 :scale: 50 % 163 -
main/waeup.kofa/trunk/docs/source/userdocs/students/browser.rst
r13099 r13101 72 72 73 73 74 .. _clearance_form_locking: 75 76 Clearance Form Locking 77 ====================== 78 79 80 81 82 83 74 84 .. _transferring_students: 75 85
Note: See TracChangeset for help on using the changeset viewer.