[13028] | 1 | .. _logging_in_as_student: |
---|
| 2 | |
---|
[13084] | 3 | Impersonate Students |
---|
| 4 | ==================== |
---|
[13026] | 5 | |
---|
[13048] | 6 | Officers with |
---|
| 7 | :py:class:`LoginAsStudent<waeup.kofa.students.permissions.LoginAsStudent>` |
---|
| 8 | permission do see a 'Login as student' button on student display |
---|
| 9 | pages which redirects to a page, where a temporary student password |
---|
| 10 | can be set by clicking a 'Set password now' form button. The |
---|
| 11 | temporary password is valid for 10 minutes. During this period the |
---|
| 12 | student can't login. The officer is being redirected to a login page |
---|
| 13 | which allows to directly login as student with pre-filled temporary |
---|
| 14 | credentials. The second page is to avoid that officers must remember |
---|
| 15 | the student credentials, have to logout from their own account and |
---|
| 16 | manually login as student via the regular login page. After 10 |
---|
| 17 | minutes the officer is automatically thrown out and the student is |
---|
| 18 | able to login again (if the officer hasn't changed the password). |
---|
| 19 | Attention: When logging in as student, the officer really |
---|
| 20 | impersonates the student. All actions are logged with the student id |
---|
| 21 | and not with the officer's user id. However, start of student |
---|
| 22 | impersonation is also logged, so that officers can be identified and |
---|
| 23 | fraudulent use can be discovered. |
---|
[13026] | 24 | |
---|
[13028] | 25 | |
---|
[13084] | 26 | .. _personal_data: |
---|
| 27 | |
---|
| 28 | Personal Data |
---|
| 29 | ============= |
---|
| 30 | |
---|
| 31 | |
---|
| 32 | .. _starting_clearance: |
---|
| 33 | |
---|
| 34 | Starting Clearance |
---|
| 35 | ================== |
---|
| 36 | |
---|
| 37 | |
---|
[13028] | 38 | .. _rejecting_clearance: |
---|
| 39 | |
---|
[13025] | 40 | Rejecting Clearance |
---|
| 41 | =================== |
---|
| 42 | |
---|
[13048] | 43 | When a clearance officer clicks the 'Save comment and reject |
---|
| 44 | clearance now' button, the `reject` action method of the |
---|
| 45 | :py:class:`StudentRejectClearancePage<waeup.kofa.students.browser.StudentRejectClearancePage>` |
---|
| 46 | is called. This method first checks, in which workflow state the |
---|
| 47 | student is, and fires a transition accordingly. Then the comment, |
---|
| 48 | which should explain why the request was requested, is saved twice |
---|
| 49 | in the `officer_comment` attribute of the student and in |
---|
| 50 | ``students.log``. As soon as the `clear` transition (d) is effected, |
---|
| 51 | an event handler clears the attribute again. The logfile message is |
---|
| 52 | permanent and ensures that the original cause of rejection can |
---|
| 53 | always be reconstructed. |
---|
[13028] | 54 | |
---|
[13054] | 55 | Finally, the method redirects to the `ContactStudentFormPage` and prefills |
---|
[13048] | 56 | the HTML form with the comment previously saved. The clearance |
---|
| 57 | officer can leave the comment as it is, or can modify the text to |
---|
| 58 | give more information about the reason of rejection. This comment |
---|
| 59 | will then be sent to the student by email. This comment is not saved, |
---|
| 60 | neither in the student object nor in the logfile. |
---|
[13028] | 61 | |
---|
| 62 | .. important:: |
---|
| 63 | |
---|
[13048] | 64 | All messages sent via Kofa contact forms are private. They are |
---|
| 65 | neither stored in the database nor in any logfile. The emails are |
---|
| 66 | also not forwarded to any other email address. Thus senders and |
---|
| 67 | recipients can be sure that nobody else is eavesdropping and the |
---|
| 68 | correspondence is kept secret. |
---|
[13028] | 69 | |
---|
[13046] | 70 | .. seealso:: |
---|
[13028] | 71 | |
---|
[13046] | 72 | :ref:`Clearance Handling Doctests <test_handle_clearance>` |
---|
| 73 | |
---|
| 74 | |
---|
[13028] | 75 | .. _transferring_students: |
---|
| 76 | |
---|
[13040] | 77 | Student Transfer |
---|
| 78 | ================ |
---|
[13025] | 79 | |
---|
[13048] | 80 | Transferring a student means enabling the student to study another |
---|
| 81 | programme. |
---|
[13028] | 82 | |
---|
[13048] | 83 | The simple but dirty way is to select another certificate and adjust |
---|
| 84 | study course attributes accordingly. Existing study levels can be |
---|
| 85 | either removed or, in case registered courses can be credited, left |
---|
| 86 | as they are. This simple way is tedious and also dangerous, because |
---|
| 87 | changes are not tracable. Only the logfile can tell us, that an |
---|
| 88 | officer has edited the student's data. The data of the previous |
---|
| 89 | study course are not backed up. They are lost. |
---|
[13028] | 90 | |
---|
[13048] | 91 | Kofa provides a more adequate, cleaner and tracable way of |
---|
| 92 | transferring students. It can make a backup of the entire study |
---|
| 93 | course container and create a new and empty container for the new |
---|
| 94 | study programme with only one click or even by batch processing. |
---|
[13028] | 95 | |
---|
[13048] | 96 | After clicking the 'Transfer student' button the |
---|
| 97 | `StudentTransferFormPage` opens and asks for the new certificate, |
---|
| 98 | current session, current level and current verdict. After submitting |
---|
| 99 | this form, the student transfer method checks if the old study |
---|
| 100 | course is complete and ready for transfer. It also checks if the |
---|
| 101 | number of possible transfers is not exceeded. Kofa allows two (2) |
---|
| 102 | transfers! Finally the copying process is started and history and |
---|
| 103 | logfile messages are added. |
---|
[13028] | 104 | |
---|
[13048] | 105 | The old study course container(s) can still be accessed via links on |
---|
[13054] | 106 | the current study course display form page. But, they can neither be |
---|
[13048] | 107 | edited, removed, exported or reimported. |
---|
[13028] | 108 | |
---|
[13046] | 109 | |
---|
[13028] | 110 | Batch Transferring Students |
---|
| 111 | --------------------------- |
---|
| 112 | |
---|
[13048] | 113 | Sometimes students of an entire study programme have to be |
---|
| 114 | transferred to another programme. This can be done with the |
---|
| 115 | :py:class:`StudentStudyCourseProcessor<waeup.kofa.students.batching.StudentStudyCourseProcessor>`. |
---|
| 116 | The import file must contain the following columns: `student_id` |
---|
| 117 | (or any other locator), `certificate`, `current_session`, |
---|
| 118 | `current_level` and `entry_mode`. Do not import `entry_session`. A |
---|
| 119 | transfer is automatically initialized if the `entry_mode` value is |
---|
| 120 | ``transfer``. |
---|
[13028] | 121 | |
---|
[13046] | 122 | |
---|
[13040] | 123 | Reverting Previous Transfers |
---|
| 124 | ---------------------------- |
---|
[13028] | 125 | |
---|
[13048] | 126 | Previous transfers can be reverted by opening the previous study |
---|
| 127 | course and clicking the 'Reactivate this study course (revert |
---|
| 128 | previous transfer)' button. This is a complete rollback of the last |
---|
| 129 | transfer. The current study mode will be irrevocably deleted and |
---|
| 130 | replaced by the previous study course. The second last study course |
---|
| 131 | will become the previous study course. |
---|
[13028] | 132 | |
---|
[13046] | 133 | |
---|
[13040] | 134 | .. _payment_tickets: |
---|
[13028] | 135 | |
---|
[13045] | 136 | Payments |
---|
| 137 | ======== |
---|
[13025] | 138 | |
---|
[13048] | 139 | The `PaymentsManageFormPage` is used by both students and students |
---|
| 140 | officers. The page tabulates existing payment tickets and allows to |
---|
| 141 | add or remove tickets. Officers can remove all payment tickets, |
---|
| 142 | students only those without a response code (`r_code`). Attention: |
---|
| 143 | Students can remove tickets without response code even if they have |
---|
| 144 | been marked paid. |
---|
[13025] | 145 | |
---|
[13048] | 146 | There are three different add form pages to add |
---|
| 147 | `StudentOnlinePayment` instances (= payment tickets). They all |
---|
| 148 | create objects of the same type, only their attributes are set |
---|
| 149 | differently. |
---|
[13040] | 150 | |
---|
[13046] | 151 | |
---|
[13040] | 152 | Current Session Payment Tickets |
---|
| 153 | ------------------------------- |
---|
| 154 | |
---|
[13048] | 155 | Current session payments are the regular payments which have to be |
---|
| 156 | made in each session to proceed to the next registration step. The |
---|
| 157 | add form provides a select box of available payment categories |
---|
| 158 | (`p_category`). After submitting the form, Kofa determines the total |
---|
| 159 | amount and sets attributes like payment item (`p_item`), payment |
---|
| 160 | session (`p_session`) and payment level (`p_level`) automatically. |
---|
| 161 | The Boolean `p_current` attribute is set ``True``. The creation |
---|
| 162 | datetime is stored in the `creation_date` attribute and is also used |
---|
| 163 | to construct the unique payment id (`p_id`). |
---|
[13040] | 164 | |
---|
| 165 | .. note:: |
---|
| 166 | |
---|
[13048] | 167 | Kofa always determines the total amount, including any fees charged |
---|
| 168 | by the school and its service providers. This is the amount which is |
---|
| 169 | authorized by students and finally submitted to one of the payment |
---|
| 170 | gateways. No fees can be added once the payment ticket is created. |
---|
| 171 | Payment tickets do not store any information about charged fees. |
---|
[13040] | 172 | |
---|
[13046] | 173 | |
---|
[13047] | 174 | Payment Ticket Redemption |
---|
| 175 | ------------------------- |
---|
[13041] | 176 | |
---|
[13048] | 177 | Directly after a student payment ticket has been paid - either by |
---|
| 178 | approval by an officer or by receiving a positive response from a |
---|
| 179 | payment gateway - the |
---|
| 180 | :py:meth:`redeemTicket<waeup.kofa.students.payments.StudentOnlinePayment.redeemTicket>` |
---|
| 181 | method is called. Depending on the category of the payment, an |
---|
| 182 | appropriate access or activation code is beeing created for the |
---|
| 183 | owner of the ticket. This code must be entered on certain form pages |
---|
| 184 | to activate the paid service or to access the next stage of the |
---|
| 185 | registration process. In other words, making a payment and redeeming |
---|
| 186 | a payment are two different steps. Successful payments do not |
---|
| 187 | automatically trigger any action in the portal but create a specifc |
---|
| 188 | access code which can be used to trigger access-code-related actions |
---|
| 189 | (see :ref:`accesscodes`). |
---|
[13041] | 190 | |
---|
[13048] | 191 | Until May 2015 also school fee payments had produced access codes, |
---|
| 192 | which enabled students to start the next session. Since software |
---|
| 193 | revision 12889, Kofa bypasses SFE access code creation and starts |
---|
| 194 | the next session automatically. |
---|
[13041] | 195 | |
---|
[13046] | 196 | |
---|
[13040] | 197 | Previous Session Payment Tickets |
---|
| 198 | -------------------------------- |
---|
| 199 | |
---|
[13048] | 200 | Previous session payments are additional payments which do not |
---|
| 201 | induce further actions in Kofa. Their sole purpose is to enable |
---|
| 202 | students to pay for services in previous sessions which they missed |
---|
| 203 | to pay. The add form for previous session payments allows the |
---|
| 204 | student to select the payment category, session and level by |
---|
| 205 | him/herself. |
---|
[13040] | 206 | |
---|
[13046] | 207 | |
---|
[13040] | 208 | Balance Payment Tickets |
---|
| 209 | ----------------------- |
---|
| 210 | |
---|
[13048] | 211 | Balance payments have been introduced to correct previously made |
---|
| 212 | payments. In some cases, students select the wrong payment category, |
---|
| 213 | or other things may have happened which led students pay less than |
---|
| 214 | expected. This can be balanced by paying a differential amount. |
---|
| 215 | Therefore, the add form for balance payments allows to freely choose |
---|
| 216 | the total amount to be paid. It also asks for the category, the |
---|
| 217 | session and the level the payment is meant for. Like previous |
---|
| 218 | session payments, balance payments do not induce further actions in |
---|
| 219 | Kofa. Both can be omitted in customized versions of Kofa if these |
---|
| 220 | features are not needed. |
---|
[13040] | 221 | |
---|
[13046] | 222 | .. _course_registration: |
---|
| 223 | |
---|
[13045] | 224 | Course Registration |
---|
| 225 | =================== |
---|
| 226 | |
---|
[13048] | 227 | Study levels are pre-filled with course tickets. When adding a study |
---|
| 228 | level, |
---|
| 229 | :py:meth:`StudentStudyCourse.addStudentStudyLevel<waeup.kofa.students.studycourse.StudentStudyCourse.addStudentStudyLevel>` |
---|
| 230 | automatically adds course tickets in two steps: |
---|
[13045] | 231 | |
---|
[13048] | 232 | 1. :py:meth:`StudentStudyLevel.addCertCourseTickets<waeup.kofa.students.studylevel.StudentStudyLevel.addCertCourseTickets>` |
---|
| 233 | is called which iterates over the certificate courses of the |
---|
| 234 | certificate container object in the academic section and creates |
---|
| 235 | course tickets if the `level` attribute matches. `title`, `fcode`, |
---|
| 236 | `dcode`, `credits`, `passmark` and `semester` are copied from the |
---|
| 237 | course object which is attached to the certificate course; |
---|
| 238 | `mandatory` is taken from the certificate course itself. Finally, |
---|
| 239 | `automatic` is set to ``True`` and `carry_over` to ``False.`` |
---|
[13045] | 240 | |
---|
[13048] | 241 | 2. The portal can be configured |
---|
| 242 | (`IConfigurationContainer.carry_over`) such that failed courses are |
---|
| 243 | automatically carried over from one session to the next. Failed |
---|
| 244 | course tickets from the previous level, i.e. tickets with a score |
---|
| 245 | below the passmark, are collected and 'copied' into the current |
---|
| 246 | study level container. The attributes `automatic` and `carry_over` |
---|
| 247 | are set to ``True``. |
---|
[13045] | 248 | |
---|
[13048] | 249 | In most cases such an automatically created course list is not |
---|
| 250 | perfect or even ready for submission to the course adviser. The list |
---|
| 251 | must be edited according to the student's needs. Students can select |
---|
| 252 | further courses, which they desire to attend, and can create |
---|
| 253 | additional course tickets, as long as the total number of credits do |
---|
| 254 | not exceed 50 (value customizable). Course tickets can also be |
---|
| 255 | removed. Whereas officers can remove any ticket from the list, |
---|
| 256 | students can remove only optional (non-mandatory) course tickets |
---|
| 257 | (condition customizable). |
---|
[13045] | 258 | |
---|
[13048] | 259 | The edit form page provides a 'Register course list' button which |
---|
[13052] | 260 | submits the course list to the course adviser for validation. If the |
---|
| 261 | course registration deadline |
---|
| 262 | (`ISessionConfiguration.coursereg_deadline`) is set and the |
---|
| 263 | registration period has expired, a late registration fee |
---|
[13053] | 264 | (`ISessionConfiguration.late_registration_fee`) is charged. This |
---|
[13052] | 265 | payment has to be made first, otherwise a warning message appears in |
---|
| 266 | the browser. |
---|
[13045] | 267 | |
---|
[13052] | 268 | Course advisers can't edit the registered/submitted course list, but |
---|
| 269 | they can validate or reject it by pressing the same-named link |
---|
| 270 | buttons. After pressing the 'Reject courses' button, Kofa redirects |
---|
[13054] | 271 | to the `ContactStudentFormPage` which can be used to inform the student |
---|
[13052] | 272 | about the reason of rejection. In contrast to clearance rejection, |
---|
| 273 | the message, which is being sent to the student by email, is neither |
---|
| 274 | stored in the database nor in the logfiles. |
---|
| 275 | |
---|
[13046] | 276 | .. seealso:: |
---|
[13045] | 277 | |
---|
[13046] | 278 | :ref:`Course List Validation Doctests <test_handle_courses>` |
---|
| 279 | |
---|
| 280 | |
---|
| 281 | .. _batch_editing_scores: |
---|
| 282 | |
---|
| 283 | Batch Editing Scores by Lecturers |
---|
| 284 | ================================= |
---|
| 285 | |
---|
[13048] | 286 | Lecturers cannot access student records directly. They don't have |
---|
[13076] | 287 | access to the students section. Instead, lecturers go to their course |
---|
[13048] | 288 | in the academic section and view or export lists of students who |
---|
| 289 | attended the course, either in a previous or in the current session. |
---|
| 290 | They do also see an 'Update scores' link button which opens the |
---|
| 291 | `EditScoresPage` if score editing is enabled for that department |
---|
| 292 | (`IDepartment.score_editing_disabled`) and |
---|
| 293 | `IConfigurationContainer.current_academic_session` has been set on |
---|
| 294 | the portal's configuration page. The `EditScoresPage` lists all |
---|
| 295 | students, who are attending the course in the current academic |
---|
| 296 | session. Score editing is allowed if the student's current session |
---|
| 297 | corresponds with the current academic session and the student is in |
---|
| 298 | state 'courses validated', see method |
---|
| 299 | :py:meth:`CourseTicket.editable_by_lecturer<waeup.kofa.students.studylevel.CourseTicket.editable_by_lecturer>`. |
---|
[13046] | 300 | |
---|
| 301 | .. seealso:: |
---|
| 302 | |
---|
| 303 | :ref:`Batch Editing Scores Doctests <test_batch_editing_scores>` |
---|
| 304 | |
---|
| 305 | |
---|
[13047] | 306 | .. _bed_tickets: |
---|
[13046] | 307 | |
---|
[13047] | 308 | Bed Tickets |
---|
| 309 | =========== |
---|
[13045] | 310 | |
---|
[13047] | 311 | Students can obtain a bed ticket if a series of conditions is met: |
---|
[13046] | 312 | |
---|
[13048] | 313 | - The current date must be inside the booking period (between |
---|
| 314 | `IHostelsContainer.startdate` and `IHostelsContainer.enddate`). |
---|
[13046] | 315 | |
---|
[13048] | 316 | - The student's current session must match the accommodation session |
---|
| 317 | (`IHostelsContainer.accommodation_session`). |
---|
[13040] | 318 | |
---|
[13047] | 319 | - A bed ticket for the same accommodation session does not exist. |
---|
| 320 | |
---|
[13048] | 321 | - The student must be in the correct workflow state |
---|
| 322 | (`IHostelsContainer.accommodation_states`). |
---|
[13047] | 323 | |
---|
| 324 | - A bed type, which fits to the student, can be determined. |
---|
| 325 | |
---|
| 326 | - A bed of that type is available. |
---|
| 327 | |
---|
| 328 | - The HOS activation code is not yet used. |
---|
| 329 | |
---|
| 330 | - The student is the owner of the activation code. |
---|
| 331 | |
---|
[13048] | 332 | The customizable utility method |
---|
| 333 | :py:meth:`getAccommodationDetails<waeup.kofa.students.utils.StudentsUtils.getAccommodationDetails>` |
---|
| 334 | composes a bed type string. Three criteria are checked: Is the |
---|
| 335 | student a new, a returning or a final year student? Is the student |
---|
| 336 | female or male? Has the student to be accommodated in a special |
---|
| 337 | hostel (`IHostel.special_handling`)? The resulting bed type string |
---|
| 338 | contains these information. Example: ``regular_female_fr`` means |
---|
| 339 | that a bed for a new female student in a regular hostel is wanted. |
---|
| 340 | If the student record allows to determine such a bed string, Kofa |
---|
| 341 | starts searching a proper bed space. |
---|
[13047] | 342 | |
---|
[13048] | 343 | Before Kofa searches for a free bed space, which meets the bed type |
---|
| 344 | criteria above, it checks if a bed space has already been allocated |
---|
| 345 | manually to the student. If so, then this bed is used, no matter |
---|
| 346 | whether the bed meets the criteria or not. (Theoretically, a male |
---|
| 347 | student can be accommodated in a hostel which is reserved for female |
---|
| 348 | students.) If no manually allocated bed space is found, Kofa |
---|
| 349 | searches for the right space. If bed booking is subject to a charge, |
---|
| 350 | Kofa also checks, if the student has entered a valid activation code, |
---|
| 351 | before delivering the bed coordinates to the student. |
---|
[13047] | 352 | |
---|
| 353 | |
---|
[13072] | 354 | Relocation |
---|
| 355 | ---------- |
---|
[13040] | 356 | |
---|
[13048] | 357 | Officers with `ManageHostels` permission do see a 'Relocate student' |
---|
[13054] | 358 | link button which calls the `BedTicketRelocationView`. This view |
---|
[13048] | 359 | relocates the student if student parameters or the bed type of the |
---|
| 360 | bed have changed. The `update` method of this view checks first, if |
---|
| 361 | the student has a 'reserved' bed space. Students in reserved beds |
---|
| 362 | are never subject to relocation. It checks secondly, if booking has |
---|
| 363 | been cancelled in the accommodation section but other bed space has |
---|
| 364 | been manually allocated after cancellation. Then this bed is used, |
---|
| 365 | no matter whether the bed meets the bed type criteria or not. If |
---|
| 366 | both checks are negative, Kofa searches for a free bed space, which |
---|
| 367 | meets the student's bed type criteria. Only if it finds a new and |
---|
| 368 | free bed space, it starts the relocation process by releasing the |
---|
| 369 | old bed, booking the new bed and designating the new bed in the bed |
---|
| 370 | ticket. |
---|
[13025] | 371 | |
---|
[13047] | 372 | .. seealso:: |
---|
[13025] | 373 | |
---|
[13047] | 374 | :ref:`Bed Space Booking Doctests <test_handle_accommodation>` |
---|