| 1 | .. _students_browser: |
|---|
| 2 | |
|---|
| 3 | Browsing the Student Section |
|---|
| 4 | ============================ |
|---|
| 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. |
|---|
| 7 | |
|---|
| 8 | |
|---|
| 9 | .. _page_layout: |
|---|
| 10 | |
|---|
| 11 | Page Layout |
|---|
| 12 | =========== |
|---|
| 13 | |
|---|
| 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. |
|---|
| 17 | |
|---|
| 18 | |
|---|
| 19 | .. _manage_edit_pages: |
|---|
| 20 | |
|---|
| 21 | Manage and Edit Pages |
|---|
| 22 | ===================== |
|---|
| 23 | |
|---|
| 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. |
|---|
| 25 | |
|---|
| 26 | .. note:: |
|---|
| 27 | |
|---|
| 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. |
|---|
| 31 | |
|---|
| 32 | |
|---|
| 33 | .. _action_buttons: |
|---|
| 34 | |
|---|
| 35 | Action Buttons |
|---|
| 36 | ============== |
|---|
| 37 | |
|---|
| 38 | There are two kinds of action buttons which appear on pages: |
|---|
| 39 | |
|---|
| 40 | - **Link Buttons** appear on top of the page above the page |
|---|
| 41 | title and are decorated with an icon. These |
|---|
| 42 | :py:class:`action |
|---|
| 43 | buttons<waeup.kofa.browser.viewlets.ActionButton>` have a |
|---|
| 44 | link target which means they usually refer to another Kofa |
|---|
| 45 | page and are sending GET requests to open the page. |
|---|
| 46 | |
|---|
| 47 | - **Form Buttons** are submit buttons which appear below a form. |
|---|
| 48 | They are HTML form actions which submit data by sending a |
|---|
| 49 | POST request back to the form page. A form page method is |
|---|
| 50 | called and processes the data or simply redirects to |
|---|
| 51 | another Kofa page. |
|---|
| 52 | |
|---|
| 53 | |
|---|
| 54 | .. _logging_in_as_student: |
|---|
| 55 | |
|---|
| 56 | Logging in as Student |
|---|
| 57 | ===================== |
|---|
| 58 | |
|---|
| 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. |
|---|
| 60 | |
|---|
| 61 | |
|---|
| 62 | .. _rejecting_clearance: |
|---|
| 63 | |
|---|
| 64 | Rejecting Clearance |
|---|
| 65 | =================== |
|---|
| 66 | |
|---|
| 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 comnent is not saved, neither in the student object nor in the logfile. |
|---|
| 70 | |
|---|
| 71 | .. important:: |
|---|
| 72 | |
|---|
| 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 | |
|---|
| 75 | |
|---|
| 76 | .. _transferring_students: |
|---|
| 77 | |
|---|
| 78 | Student Transfer |
|---|
| 79 | ================ |
|---|
| 80 | |
|---|
| 81 | Transferring a student means enabling the student to study another programme. |
|---|
| 82 | |
|---|
| 83 | 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. |
|---|
| 84 | |
|---|
| 85 | 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. |
|---|
| 86 | |
|---|
| 87 | 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. |
|---|
| 88 | |
|---|
| 89 | 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 | |
|---|
| 91 | Batch Transferring Students |
|---|
| 92 | --------------------------- |
|---|
| 93 | |
|---|
| 94 | 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 | |
|---|
| 96 | Reverting Previous Transfers |
|---|
| 97 | ---------------------------- |
|---|
| 98 | |
|---|
| 99 | 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 | |
|---|
| 101 | .. _payment_tickets: |
|---|
| 102 | |
|---|
| 103 | Payment Tickets |
|---|
| 104 | =============== |
|---|
| 105 | |
|---|
| 106 | 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. |
|---|
| 107 | |
|---|
| 108 | 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 | |
|---|
| 110 | Current Session Payment Tickets |
|---|
| 111 | ------------------------------- |
|---|
| 112 | |
|---|
| 113 | 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`). |
|---|
| 114 | |
|---|
| 115 | .. note:: |
|---|
| 116 | |
|---|
| 117 | 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 | |
|---|
| 119 | Ticket Redemption |
|---|
| 120 | ----------------- |
|---|
| 121 | |
|---|
| 122 | 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 |
|---|
| 123 | :py:meth:`redeemTicket<waeup.kofa.students.payments.StudentOnlinePayment.redeemTicket>` method is called. Depending on the category of the payment, usually 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 a 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`). |
|---|
| 124 | |
|---|
| 125 | Until May 2015 also school fee payments had produced access codes which enabled students to start the next session. Meanwile, Kofa bypasses SFE access code creation if next session can be started directly. |
|---|
| 126 | |
|---|
| 127 | Previous Session Payment Tickets |
|---|
| 128 | -------------------------------- |
|---|
| 129 | |
|---|
| 130 | 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 | |
|---|
| 132 | Balance Payment Tickets |
|---|
| 133 | ----------------------- |
|---|
| 134 | |
|---|
| 135 | 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 amount to be paid. It also asks for the category, the session and the level the payment is meant for. Like previous session paymnets, balance payments do not induce further actions in Kofa. Both can be omitted in customized versions of Kofa. |
|---|
| 136 | |
|---|
| 137 | Bed Tickets |
|---|
| 138 | =========== |
|---|
| 139 | |
|---|
| 140 | Bed Relocation |
|---|
| 141 | -------------- |
|---|
| 142 | |
|---|
| 143 | Course Tickets |
|---|
| 144 | ============== |
|---|
| 145 | |
|---|
| 146 | Course Registration |
|---|
| 147 | =================== |
|---|
| 148 | |
|---|
| 149 | Requesting a Password |
|---|
| 150 | ===================== |
|---|
| 151 | |
|---|
| 152 | Editing Scores by Lecturers |
|---|
| 153 | =========================== |
|---|
| 154 | |
|---|
| 155 | .. _bootstrap: http://getbootstrap.com/ |
|---|
| 156 | |
|---|
| 157 | .. _zope schema: http://docs.zope.org/zope.schema |
|---|
| 158 | |
|---|
| 159 | .. _zope formlib: http://bluebream.zope.org/doc/1.0/manual/schema.html#auto-generated-forms-using-the-forms-package |
|---|
