Changeset 13046 for main/waeup.kofa/trunk/docs/source/userdocs
- Timestamp:
- 14 Jun 2015, 11:33:07 (9 years ago)
- Location:
- main/waeup.kofa/trunk/docs/source/userdocs
- Files:
-
- 2 edited
-
students/browser.rst (modified) (10 diffs)
-
testing.rst (modified) (2 diffs)
Legend:
- Unmodified
- Added
- Removed
-
main/waeup.kofa/trunk/docs/source/userdocs/students/browser.rst
r13045 r13046 73 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. 74 74 75 .. seealso:: 76 77 :ref:`Clearance Handling Doctests <test_handle_clearance>` 78 75 79 76 80 .. _transferring_students: … … 89 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. 90 94 95 91 96 Batch Transferring Students 92 97 --------------------------- … … 94 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``. 95 100 101 96 102 Reverting Previous Transfers 97 103 ---------------------------- … … 99 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. 100 106 107 101 108 .. _payment_tickets: 102 109 … … 108 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. 109 116 117 110 118 Current Session Payment Tickets 111 119 ------------------------------- … … 117 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. 118 126 127 119 128 Ticket Redemption 120 129 ----------------- … … 125 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. 126 135 136 127 137 Previous Session Payment Tickets 128 138 -------------------------------- … … 130 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. 131 141 142 132 143 Balance Payment Tickets 133 144 ----------------------- … … 135 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. 136 147 148 .. _course_registration: 149 137 150 Course Registration 138 151 =================== … … 142 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.`` 143 156 144 2. The portal can be configured 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``.145 146 In most cases , such an automatically created course list is not perfect or even ready for submission to the course adviser. The list has tobe 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 total 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).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 total 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). 147 160 148 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. 149 162 150 Editing Scores by Lecturers 151 =========================== 163 .. seealso:: 164 165 :ref:`Course List Validation Doctests <test_handle_courses>` 166 167 168 .. _batch_editing_scores: 169 170 Batch Editing Scores by Lecturers 171 ================================= 172 173 Lecturer cannot access student data 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 page lists all students, who are attending the course in the current academic session. If score editing is allowed, the score can be entered at the end of the student line. 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>` 174 175 .. seealso:: 176 177 :ref:`Batch Editing Scores Doctests <test_batch_editing_scores>` 178 179 180 .. _requesting_new_password: 152 181 153 182 Requesting New Password 154 183 ======================= 155 184 185 186 .. bed_tickets: 187 156 188 Bed Tickets 157 189 =========== -
main/waeup.kofa/trunk/docs/source/userdocs/testing.rst
r12964 r13046 171 171 `browser.contents` (is the HTML content of the opened page). 172 172 173 173 174 .. _test_suspended_officer: 174 175 … … 188 189 <officers>`. 189 190 190 Further tests will follow soon. 191 192 .. _test_handle_clearance: 193 194 Handle Clearance by Clearance Officer 195 ------------------------------------- 196 197 This test can be found in 198 `waeup.kofa.students.tests.test_browser.OfficerUITests`: 199 200 .. literalinclude:: ../../../src/waeup/kofa/students/tests/test_browser.py 201 :pyobject: test_handle_clearance_by_co 202 203 204 .. _test_handle_courses: 205 206 Handle Course List Validation by Course Adviser 207 ----------------------------------------------- 208 209 This test can be found in 210 `waeup.kofa.students.tests.test_browser.OfficerUITests`: 211 212 .. literalinclude:: ../../../src/waeup/kofa/students/tests/test_browser.py 213 :pyobject: test_handle_courses_by_ca 214 215 216 .. _test_batch_editing_scores: 217 218 Batch Editing Scores by Lecturers 219 --------------------------------- 220 221 This test can be found in 222 `waeup.kofa.students.tests.test_browser.OfficerUITests`: 223 224 .. literalinclude:: ../../../src/waeup/kofa/students/tests/test_browser.py 225 :pyobject: test_handle_courses_by_lecturer
Note: See TracChangeset for help on using the changeset viewer.
