Changeset 13048
- Timestamp:
- 15 Jun 2015, 09:14:47 (9 years ago)
- Location:
- main/waeup.kofa/trunk/docs/source/userdocs
- Files:
-
- 2 edited
-
students.rst (modified) (1 diff)
-
students/browser.rst (modified) (18 diffs)
Legend:
- Unmodified
- Added
- Removed
-
main/waeup.kofa/trunk/docs/source/userdocs/students.rst
r13025 r13048 64 64 students/workflow 65 65 66 Browser Pages :sup:`in progress`67 ============= ====================66 Browser Pages 67 ============= 68 68 69 69 .. toctree:: -
main/waeup.kofa/trunk/docs/source/userdocs/students/browser.rst
r13047 r13048 4 4 ============================ 5 5 6 The reader may ask: How do officers and students browse the portal? Where are the step-by-step operating instructions on how to use Kofa? We are always tempted to answer: The menu navigation should be self-explanatory and it's quite easy to follow the menu prompts or flash messages which appear above page titles in a green, yellow or red box. For the students section this answer seems a bit over the top. We must indeed describe some browser pages and what their clickable actions are doing with the data. The reason is, that a lot of Kofa's functionality is embedded in view and utility methods and not only provided by the functionality of content components as described above. 6 The reader may ask: How do officers and students browse the portal? 7 Where are the step-by-step operating instructions on how to use 8 Kofa? We are always tempted to answer: The menu navigation should be 9 self-explanatory and it's quite easy to follow the menu prompts or 10 flash messages which appear above page titles in a green, yellow or 11 red box. For the students section this answer seems a bit over the 12 top. We must indeed describe some browser pages and what their 13 clickable actions are doing with the data. The reason is, that a lot 14 of Kofa's functionality is embedded in view and utility methods and 15 not only provided by the functionality of content components as 16 described above. 7 17 8 18 … … 12 22 =========== 13 23 14 Kofa makes use of two different `Bootstrap`_ layouts. Anonymous users, students and applicants do see a single-column theme with only a static top navigation bar. Students can navigate to the various display pages of their record by pulling down the 'My Data' in the navigation bar. 15 16 Officers see a double-column theme after logging in. The left column contains a box which contains links to the user's preferences (My Preferences) and roles (My Roles). It also contains links to the various sections of Kofa depending on the permissions the officer has has obtained. Possible sections are: 'Portal Configuration', 'Officers', 'Data Center', 'Reports' and 'Access Codes'. A second box shows up in the left column when the officer accesses a student record. This box gives direct access to the display pages of a student record. 24 Kofa makes use of two different `Bootstrap`_ layouts. Anonymous 25 users, students and applicants do see a single-column theme with 26 only a static top navigation bar. Students can navigate to the 27 various display pages of their record by pulling down the 'My Data' 28 in the navigation bar. 29 30 Officers see a double-column theme after logging in. The left column 31 contains a box which contains links to the user's preferences (My 32 Preferences) and roles (My Roles). It also contains links to the 33 various sections of Kofa depending on the permissions the officer 34 has has obtained. Possible sections are: 'Portal Configuration', 35 'Officers', 'Data Center', 'Reports' and 'Access Codes'. A second 36 box shows up in the left column when the officer accesses a student 37 record. This box gives direct access to the display pages of a 38 student record. 17 39 18 40 … … 22 44 ===================== 23 45 24 Pages, or more precisely web pages, are browser views which render (produce) HTML or PDF code to be displayed in a web browser or a pdf reader respectively. Views are dealing with request and response objects. In Kofa most pages are form pages which means they are views on data. These pages are either used to display, edit or add persistant data. Thus we can further distinguish display, edit and add form pages. Kofa is using the `Zope Formlib`_ package to auto-generate these forms. 46 Pages, or more precisely web pages, are browser views which render 47 (produce) HTML or PDF code to be displayed in a web browser or a pdf 48 reader respectively. Views are dealing with request and response 49 objects. In Kofa most pages are form pages which means they are 50 views on data. These pages are either used to display, edit or add 51 persistant data. Thus we can further distinguish display, edit and 52 add form pages. Kofa is using the `Zope Formlib`_ package to 53 auto-generate these forms. 25 54 26 55 .. note:: 27 56 28 Briefly, Zope Formlib is wedded to `Zope Schema`_, it provides display and input widgets (= views) for the fields defined in the Zope Schema package. Auto-generation is done with `grok.AutoFields` which takes the fields, declared in an interface, and renders display or input widgets, according to the schema declaration, for display or edit forms respectively. 29 30 Whereas display and add form pages are usually shared by officers and students, edit form pages are not. Students are not allowed to edit all of their data all the time. Edit access is restricted by workflow states or other conditions. Officers' access is much less restricted and we therefore speak of 'managing' instead of 'editing' data. In most cases, Kofa uses two different form pages which require different permissions: An `EditFormPage` requires the :py:class:`HandleStudent<waeup.kofa.students.permissions.HandleStudent>` permission and a `ManageFormPage` requires the :py:class:`ManageStudent<waeup.kofa.students.permissions.ManageStudent>` permission. 57 Briefly, Zope Formlib is wedded to `Zope Schema`_, it provides 58 display and input widgets (= views) for the fields defined in the 59 Zope Schema package. Auto-generation is done with `grok.AutoFields` 60 which takes the fields, declared in an interface, and renders 61 display or input widgets, according to the schema declaration, for 62 display or edit forms respectively. 63 64 Whereas display and add form pages are usually shared by officers 65 and students, edit form pages are not. Students are not allowed to 66 edit all of their data all the time. Edit access is restricted by 67 workflow states or other conditions. Officers' access is much less 68 restricted and we therefore speak of 'managing' instead of 'editing' 69 data. In most cases, Kofa uses two different form pages which 70 require different permissions: An `EditFormPage` requires the 71 :py:class:`HandleStudent<waeup.kofa.students.permissions.HandleStudent>` 72 permission and a `ManageFormPage` requires the 73 :py:class:`ManageStudent<waeup.kofa.students.permissions.ManageStudent>` 74 permission. 31 75 32 76 … … 57 101 ===================== 58 102 59 Officers with :py:class:`LoginAsStudent<waeup.kofa.students.permissions.LoginAsStudent>` permission do see a 'Login as student' button on student display pages which redirects to a page, where a temporary student password can be set by clicking a 'Set password now' form button. The temporary password is valid for 10 minutes. During this period the student can't login. The officer is being redirected to a login page which allows to directly login as student with pre-filled temporary credentials. The second page is to avoid that officers must remember the student credentials, have to logout from their own account and manually login as student via the regular login page. After 10 minutes the officer is automatically thrown out and the student is able to login again (if the officer hasn't changed the password). Attention: When logging in as student, the officer really impersonates the student. All actions are logged with the student id and not with the officer's user id. However, start of student impersonation is also logged, so that officers can be identified and fraudulent use can be discovered. 103 Officers with 104 :py:class:`LoginAsStudent<waeup.kofa.students.permissions.LoginAsStudent>` 105 permission do see a 'Login as student' button on student display 106 pages which redirects to a page, where a temporary student password 107 can be set by clicking a 'Set password now' form button. The 108 temporary password is valid for 10 minutes. During this period the 109 student can't login. The officer is being redirected to a login page 110 which allows to directly login as student with pre-filled temporary 111 credentials. The second page is to avoid that officers must remember 112 the student credentials, have to logout from their own account and 113 manually login as student via the regular login page. After 10 114 minutes the officer is automatically thrown out and the student is 115 able to login again (if the officer hasn't changed the password). 116 Attention: When logging in as student, the officer really 117 impersonates the student. All actions are logged with the student id 118 and not with the officer's user id. However, start of student 119 impersonation is also logged, so that officers can be identified and 120 fraudulent use can be discovered. 60 121 61 122 … … 65 126 =================== 66 127 67 When a clearance officer clicks the 'Save comment and reject clearance now' button, the `reject` action method of the :py:class:`StudentRejectClearancePage<waeup.kofa.students.browser.StudentRejectClearancePage>` is called. This method first checks, in which workflow state the student is, and fires a transition accordingly. Then the comment, which should explain why the request was requested, is saved twice in the `officer_comment` attribute of the student and in ``students.log``. As soon as the `clear` transition (d) is effected, an event handler clears the attribute again. The logfile message is permanent and ensures that the original cause of rejection can always be reconstructed. 68 69 Finally, the method redirects to the ContactStudentForm and prefills the HTML form with the comment previously saved. The clearance officer can leave the comment as it is, or can modify the text to give more information about the reason of rejection. This comment will then be sent to the student by email. This comment is not saved, neither in the student object nor in the logfile. 128 When a clearance officer clicks the 'Save comment and reject 129 clearance now' button, the `reject` action method of the 130 :py:class:`StudentRejectClearancePage<waeup.kofa.students.browser.StudentRejectClearancePage>` 131 is called. This method first checks, in which workflow state the 132 student is, and fires a transition accordingly. Then the comment, 133 which should explain why the request was requested, is saved twice 134 in the `officer_comment` attribute of the student and in 135 ``students.log``. As soon as the `clear` transition (d) is effected, 136 an event handler clears the attribute again. The logfile message is 137 permanent and ensures that the original cause of rejection can 138 always be reconstructed. 139 140 Finally, the method redirects to the ContactStudentForm and prefills 141 the HTML form with the comment previously saved. The clearance 142 officer can leave the comment as it is, or can modify the text to 143 give more information about the reason of rejection. This comment 144 will then be sent to the student by email. This comment is not saved, 145 neither in the student object nor in the logfile. 70 146 71 147 .. important:: 72 148 73 All messages sent via Kofa contact forms are private. They are neither stored in the database nor in any logfile. The emails are also not forwarded to any other email address. Thus senders and recipients can be sure that nobody else is eavesdropping and the correspondence is kept secret. 149 All messages sent via Kofa contact forms are private. They are 150 neither stored in the database nor in any logfile. The emails are 151 also not forwarded to any other email address. Thus senders and 152 recipients can be sure that nobody else is eavesdropping and the 153 correspondence is kept secret. 74 154 75 155 .. seealso:: … … 83 163 ================ 84 164 85 Transferring a student means enabling the student to study another programme. 86 87 The simple but dirty way is to select another certificate and adjust study course attributes accordingly. Existing study levels can be either removed or, in case registered courses can be credited, left as they are. This simple way is tedious and also dangerous, because changes are not tracable. Only the logfile can tell us, that an officer has edited the student's data. The data of the previous study course are not backed up. They are lost. 88 89 Kofa provides a more adequate, cleaner and tracable way of transferring students. It can make a backup of the entire study course container and create a new and empty container for the new study programme with only one click or even by batch processing. 90 91 After clicking the 'Transfer student' button the `StudentTransferFormPage` opens and asks for the new certificate, current session, current level and current verdict. After submitting this form, the student transfer method checks if the old study course is complete and ready for transfer. It also checks if the number of possible transfers is not exceeded. Kofa allows two (2) transfers! Finally the copying process is started and history and logfile messages are added. 92 93 The old study course container(s) can still be accessed via links on the current study course display page. But, they can neither be edited, removed, exported or reimported. 165 Transferring a student means enabling the student to study another 166 programme. 167 168 The simple but dirty way is to select another certificate and adjust 169 study course attributes accordingly. Existing study levels can be 170 either removed or, in case registered courses can be credited, left 171 as they are. This simple way is tedious and also dangerous, because 172 changes are not tracable. Only the logfile can tell us, that an 173 officer has edited the student's data. The data of the previous 174 study course are not backed up. They are lost. 175 176 Kofa provides a more adequate, cleaner and tracable way of 177 transferring students. It can make a backup of the entire study 178 course container and create a new and empty container for the new 179 study programme with only one click or even by batch processing. 180 181 After clicking the 'Transfer student' button the 182 `StudentTransferFormPage` opens and asks for the new certificate, 183 current session, current level and current verdict. After submitting 184 this form, the student transfer method checks if the old study 185 course is complete and ready for transfer. It also checks if the 186 number of possible transfers is not exceeded. Kofa allows two (2) 187 transfers! Finally the copying process is started and history and 188 logfile messages are added. 189 190 The old study course container(s) can still be accessed via links on 191 the current study course display page. But, they can neither be 192 edited, removed, exported or reimported. 94 193 95 194 … … 97 196 --------------------------- 98 197 99 Sometimes students of an entire study programme have to be transferred to another programme. This can be done with the :py:class:`StudentStudyCourseProcessor<waeup.kofa.students.batching.StudentStudyCourseProcessor>`. The import file must contain the following columns: `student_id` (or any other locator), `certificate`, `current_session`, `current_level` and `entry_mode`. Do not import `entry_session`. A transfer is automatically initialized if the `entry_mode` value is ``transfer``. 198 Sometimes students of an entire study programme have to be 199 transferred to another programme. This can be done with the 200 :py:class:`StudentStudyCourseProcessor<waeup.kofa.students.batching.StudentStudyCourseProcessor>`. 201 The import file must contain the following columns: `student_id` 202 (or any other locator), `certificate`, `current_session`, 203 `current_level` and `entry_mode`. Do not import `entry_session`. A 204 transfer is automatically initialized if the `entry_mode` value is 205 ``transfer``. 100 206 101 207 … … 103 209 ---------------------------- 104 210 105 Previous transfers can be reverted by opening the previous study course and clicking the 'Reactivate this study course (revert previous transfer)' button. This is a complete rollback of the last transfer. The current study mode will be irrevocably deleted and replaced by the previous study course. The second last study course will become the previous study course. 211 Previous transfers can be reverted by opening the previous study 212 course and clicking the 'Reactivate this study course (revert 213 previous transfer)' button. This is a complete rollback of the last 214 transfer. The current study mode will be irrevocably deleted and 215 replaced by the previous study course. The second last study course 216 will become the previous study course. 106 217 107 218 … … 111 222 ======== 112 223 113 The `PaymentsManageFormPage` is used by both students and students officers. The page tabulates existing payment tickets and allows to add or remove tickets. Officers can remove all payment tickets, students only those without a response code (`r_code`). Attention: Students can remove tickets without response code even if they have been marked paid. 114 115 There are three different add form pages to add `StudentOnlinePayment` instances (= payment tickets). They all create objects of the same type, only their attributes are set differently. 224 The `PaymentsManageFormPage` is used by both students and students 225 officers. The page tabulates existing payment tickets and allows to 226 add or remove tickets. Officers can remove all payment tickets, 227 students only those without a response code (`r_code`). Attention: 228 Students can remove tickets without response code even if they have 229 been marked paid. 230 231 There are three different add form pages to add 232 `StudentOnlinePayment` instances (= payment tickets). They all 233 create objects of the same type, only their attributes are set 234 differently. 116 235 117 236 … … 119 238 ------------------------------- 120 239 121 Current session payments are the regular payments which have to be made in each session to proceed to the next registration step. The add form provides a select box of available payment categories (`p_category`). After submitting the form, Kofa determines the total amount and sets attributes like payment item (`p_item`), payment session (`p_session`) and payment level (`p_level`) automatically. The Boolean `p_current` attribute is set ``True``. The creation datetime is stored in the `creation_date` attribute and is also used to construct the unique payment id (`p_id`). 240 Current session payments are the regular payments which have to be 241 made in each session to proceed to the next registration step. The 242 add form provides a select box of available payment categories 243 (`p_category`). After submitting the form, Kofa determines the total 244 amount and sets attributes like payment item (`p_item`), payment 245 session (`p_session`) and payment level (`p_level`) automatically. 246 The Boolean `p_current` attribute is set ``True``. The creation 247 datetime is stored in the `creation_date` attribute and is also used 248 to construct the unique payment id (`p_id`). 122 249 123 250 .. note:: 124 251 125 Kofa always determines the total amount, including any fees charged by the school and its service providers. This is the amount which is authorized by students and finally submitted to one of the payment gateways. No fees can be added once the payment ticket is created. Payment tickets do not store any information about charged fees. 252 Kofa always determines the total amount, including any fees charged 253 by the school and its service providers. This is the amount which is 254 authorized by students and finally submitted to one of the payment 255 gateways. No fees can be added once the payment ticket is created. 256 Payment tickets do not store any information about charged fees. 126 257 127 258 … … 129 260 ------------------------- 130 261 131 Directly after a student payment ticket has been paid - either by approval by an officer or by receiving a positive response from a payment gateway - the 132 :py:meth:`redeemTicket<waeup.kofa.students.payments.StudentOnlinePayment.redeemTicket>` method is called. Depending on the category of the payment, an appropriate access or activation code is beeing created for the owner of the ticket. This code must be entered on certain form pages to activate the paid service or to access the next stage of the registration process. In other words, making a payment and redeeming a payment are two different steps. Successful payments do not automatically trigger any action in the portal but create a specifc access code which can be used to trigger access-code-related actions (see :ref:`accesscodes`). 133 134 Until May 2015 also school fee payments had produced access codes, which enabled students to start the next session. Since software revision 12889, Kofa bypasses SFE access code creation and starts the next session automatically. 262 Directly after a student payment ticket has been paid - either by 263 approval by an officer or by receiving a positive response from a 264 payment gateway - the 265 :py:meth:`redeemTicket<waeup.kofa.students.payments.StudentOnlinePayment.redeemTicket>` 266 method is called. Depending on the category of the payment, an 267 appropriate access or activation code is beeing created for the 268 owner of the ticket. This code must be entered on certain form pages 269 to activate the paid service or to access the next stage of the 270 registration process. In other words, making a payment and redeeming 271 a payment are two different steps. Successful payments do not 272 automatically trigger any action in the portal but create a specifc 273 access code which can be used to trigger access-code-related actions 274 (see :ref:`accesscodes`). 275 276 Until May 2015 also school fee payments had produced access codes, 277 which enabled students to start the next session. Since software 278 revision 12889, Kofa bypasses SFE access code creation and starts 279 the next session automatically. 135 280 136 281 … … 138 283 -------------------------------- 139 284 140 Previous session payments are additional payments which do not induce further actions in Kofa. Their sole purpose is to enable students to pay for services in previous sessions which they missed to pay. The add form for previous session payments allows the student to select the payment category, session and level by him/herself. 285 Previous session payments are additional payments which do not 286 induce further actions in Kofa. Their sole purpose is to enable 287 students to pay for services in previous sessions which they missed 288 to pay. The add form for previous session payments allows the 289 student to select the payment category, session and level by 290 him/herself. 141 291 142 292 … … 144 294 ----------------------- 145 295 146 Balance payments have been introduced to correct previously made payments. In some cases, students select the wrong payment category, or other things may have happened which led students pay less than expected. This can be balanced by paying a differential amount. Therefore, the add form for balance payments allows to freely choose the total amount to be paid. It also asks for the category, the session and the level the payment is meant for. Like previous session payments, balance payments do not induce further actions in Kofa. Both can be omitted in customized versions of Kofa if these features are not needed. 296 Balance payments have been introduced to correct previously made 297 payments. In some cases, students select the wrong payment category, 298 or other things may have happened which led students pay less than 299 expected. This can be balanced by paying a differential amount. 300 Therefore, the add form for balance payments allows to freely choose 301 the total amount to be paid. It also asks for the category, the 302 session and the level the payment is meant for. Like previous 303 session payments, balance payments do not induce further actions in 304 Kofa. Both can be omitted in customized versions of Kofa if these 305 features are not needed. 147 306 148 307 .. _course_registration: … … 151 310 =================== 152 311 153 Study levels are pre-filled with course tickets. When adding a study level, :py:meth:`StudentStudyCourse.addStudentStudyLevel<waeup.kofa.students.studycourse.StudentStudyCourse.addStudentStudyLevel>` automatically adds course tickets in two steps: 154 155 1. :py:meth:`StudentStudyLevel.addCertCourseTickets<waeup.kofa.students.studylevel.StudentStudyLevel.addCertCourseTickets>` is called which iterates over the certificate courses of the certificate container object in the academic section and creates course tickets if the `level` attribute matches. `title`, `fcode`, `dcode`, `credits`, `passmark` and `semester` are copied from the course object which is attached to the certificate course; `mandatory` is taken from the certificate course itself. Finally, `automatic` is set to ``True`` and `carry_over` to ``False.`` 156 157 2. The portal can be configured (`IConfigurationContainer.carry_over`) such that failed courses are automatically carried over from one session to the next. Failed course tickets from the previous level, i.e. tickets with a score below the passmark, are collected and 'copied' into the current study level container. The attributes `automatic` and `carry_over` are set to ``True``. 158 159 In most cases such an automatically created course list is not perfect or even ready for submission to the course adviser. The list must be edited according to the student's needs. Students can select further courses, which they desire to attend, and can create additional course tickets, as long as the total number of credits do not exceed 50 (value customizable). Course tickets can also be removed. Whereas officers can remove any ticket from the list, students can remove only optional (non-mandatory) course tickets (condition customizable). 160 161 The edit form page provides a 'Register course list' button which submits the course list to the course adviser for validation. Course advisers can't edit the registered/submitted course list, but they can validate or reject it by pressing the same-named link buttons. After pressing the 'Reject courses' button, Kofa redirects to the ContactStudentForm which can be used to inform the student about the reason of rejection. In contrast to clearance rejection, the message, which is being sent to the student by email, is neither stored in the database nor in the logfiles. 312 Study levels are pre-filled with course tickets. When adding a study 313 level, 314 :py:meth:`StudentStudyCourse.addStudentStudyLevel<waeup.kofa.students.studycourse.StudentStudyCourse.addStudentStudyLevel>` 315 automatically adds course tickets in two steps: 316 317 1. :py:meth:`StudentStudyLevel.addCertCourseTickets<waeup.kofa.students.studylevel.StudentStudyLevel.addCertCourseTickets>` 318 is called which iterates over the certificate courses of the 319 certificate container object in the academic section and creates 320 course tickets if the `level` attribute matches. `title`, `fcode`, 321 `dcode`, `credits`, `passmark` and `semester` are copied from the 322 course object which is attached to the certificate course; 323 `mandatory` is taken from the certificate course itself. Finally, 324 `automatic` is set to ``True`` and `carry_over` to ``False.`` 325 326 2. The portal can be configured 327 (`IConfigurationContainer.carry_over`) such that failed courses are 328 automatically carried over from one session to the next. Failed 329 course tickets from the previous level, i.e. tickets with a score 330 below the passmark, are collected and 'copied' into the current 331 study level container. The attributes `automatic` and `carry_over` 332 are set to ``True``. 333 334 In most cases such an automatically created course list is not 335 perfect or even ready for submission to the course adviser. The list 336 must be edited according to the student's needs. Students can select 337 further courses, which they desire to attend, and can create 338 additional course tickets, as long as the total number of credits do 339 not exceed 50 (value customizable). Course tickets can also be 340 removed. Whereas officers can remove any ticket from the list, 341 students can remove only optional (non-mandatory) course tickets 342 (condition customizable). 343 344 The edit form page provides a 'Register course list' button which 345 submits the course list to the course adviser for validation. Course 346 advisers can't edit the registered/submitted course list, but they 347 can validate or reject it by pressing the same-named link buttons. 348 After pressing the 'Reject courses' button, Kofa redirects to the 349 ContactStudentForm which can be used to inform the student about the 350 reason of rejection. In contrast to clearance rejection, the message, 351 which is being sent to the student by email, is neither stored in 352 the database nor in the logfiles. 162 353 163 354 .. seealso:: … … 171 362 ================================= 172 363 173 Lecturers cannot access student records directly. They don't have access to the student section. Instead, lecturers go to their course in the academic section and view or export lists of students who attended the course, either in a previous or in the current session. They do also see an 'Update scores' link button which opens the `EditScoresPage` if score editing is enabled for that department (`IDepartment.score_editing_disabled`) and `IConfigurationContainer.current_academic_session` has been set on the portal's configuration page. The `EditScoresPage` lists all students, who are attending the course in the current academic session. Score editing is allowed if the student's current session corresponds with the current academic session and the student is in state 'courses validated', see method :py:meth:`CourseTicket.editable_by_lecturer<waeup.kofa.students.studylevel.CourseTicket.editable_by_lecturer>`. 364 Lecturers cannot access student records directly. They don't have 365 access to the student section. Instead, lecturers go to their course 366 in the academic section and view or export lists of students who 367 attended the course, either in a previous or in the current session. 368 They do also see an 'Update scores' link button which opens the 369 `EditScoresPage` if score editing is enabled for that department 370 (`IDepartment.score_editing_disabled`) and 371 `IConfigurationContainer.current_academic_session` has been set on 372 the portal's configuration page. The `EditScoresPage` lists all 373 students, who are attending the course in the current academic 374 session. Score editing is allowed if the student's current session 375 corresponds with the current academic session and the student is in 376 state 'courses validated', see method 377 :py:meth:`CourseTicket.editable_by_lecturer<waeup.kofa.students.studylevel.CourseTicket.editable_by_lecturer>`. 174 378 175 379 .. seealso:: … … 185 389 Students can obtain a bed ticket if a series of conditions is met: 186 390 187 - The current date must be inside the booking period (between `IHostelsContainer.startdate` and `IHostelsContainer.enddate`). 188 189 - The student's current session must match the accommodation session (`IHostelsContainer.accommodation_session`). 391 - The current date must be inside the booking period (between 392 `IHostelsContainer.startdate` and `IHostelsContainer.enddate`). 393 394 - The student's current session must match the accommodation session 395 (`IHostelsContainer.accommodation_session`). 190 396 191 397 - A bed ticket for the same accommodation session does not exist. 192 398 193 - The student must be in the correct workflow state (`IHostelsContainer.accommodation_states`). 399 - The student must be in the correct workflow state 400 (`IHostelsContainer.accommodation_states`). 194 401 195 402 - A bed type, which fits to the student, can be determined. … … 201 408 - The student is the owner of the activation code. 202 409 203 The customizable utility method :py:meth:`getAccommodationDetails<waeup.kofa.students.utils.StudentsUtils.getAccommodationDetails>` composes a bed type string. Three criteria are checked: Is the student a new, a returning or a final year student? Is the student female or male? Has the student to be accommodated in a special hostel (`IHostel.special_handling`)? The resulting bed type string contains these information. Example: ``regular_female_fr`` means that a bed for a new female student in a regular hostel is wanted. If the student record allows to determine such a bed string, Kofa starts searching a proper bed space. 204 205 Before Kofa searches for a free bed space, which meets the bed type criteria above, it checks if a bed space has already been allocated manually to the student. If so, then this bed is used, no matter whether the bed meets the criteria or not. (Theoretically, a male student can be accommodated in a hostel which is reserved for female students.) If no manually allocated bed space is found, Kofa searches for the right space. If bed booking is subject to a charge, Kofa also checks, if the student has entered a valid activation code, before delivering the bed coordinates to the student. 410 The customizable utility method 411 :py:meth:`getAccommodationDetails<waeup.kofa.students.utils.StudentsUtils.getAccommodationDetails>` 412 composes a bed type string. Three criteria are checked: Is the 413 student a new, a returning or a final year student? Is the student 414 female or male? Has the student to be accommodated in a special 415 hostel (`IHostel.special_handling`)? The resulting bed type string 416 contains these information. Example: ``regular_female_fr`` means 417 that a bed for a new female student in a regular hostel is wanted. 418 If the student record allows to determine such a bed string, Kofa 419 starts searching a proper bed space. 420 421 Before Kofa searches for a free bed space, which meets the bed type 422 criteria above, it checks if a bed space has already been allocated 423 manually to the student. If so, then this bed is used, no matter 424 whether the bed meets the criteria or not. (Theoretically, a male 425 student can be accommodated in a hostel which is reserved for female 426 students.) If no manually allocated bed space is found, Kofa 427 searches for the right space. If bed booking is subject to a charge, 428 Kofa also checks, if the student has entered a valid activation code, 429 before delivering the bed coordinates to the student. 206 430 207 431 … … 209 433 -------------- 210 434 211 Officers with `ManageHostels` permission do see a 'Relocate student' link button which calls the `BedTicketRelocationPage`. This view relocates the student if student parameters or the bed type of the bed have changed. The `update` method of this view checks first if the student has a 'reserved' bed space. Students in reserved beds are never subject to relocation. It checks secondly if booking has been cancelled in the accommodation section but other bed space has been manually allocated after cancellation. Then this bed is used, no matter whether the bed meets the bed type criteria or not. If both checks are negative, Kofa searches for a free bed space, which meets the student's bed type criteria. Only if it finds a new and free bed space, it starts the relocation process by releasing the old bed, booking the new bed and designating the new bed in the bed ticket. 435 Officers with `ManageHostels` permission do see a 'Relocate student' 436 link button which calls the `BedTicketRelocationPage`. This view 437 relocates the student if student parameters or the bed type of the 438 bed have changed. The `update` method of this view checks first, if 439 the student has a 'reserved' bed space. Students in reserved beds 440 are never subject to relocation. It checks secondly, if booking has 441 been cancelled in the accommodation section but other bed space has 442 been manually allocated after cancellation. Then this bed is used, 443 no matter whether the bed meets the bed type criteria or not. If 444 both checks are negative, Kofa searches for a free bed space, which 445 meets the student's bed type criteria. Only if it finds a new and 446 free bed space, it starts the relocation process by releasing the 447 old bed, booking the new bed and designating the new bed in the bed 448 ticket. 212 449 213 450 .. seealso::
Note: See TracChangeset for help on using the changeset viewer.
