Changeset 13047 for main/waeup.kofa/trunk/docs/source

Timestamp:

15 Jun 2015, 08:57:24 (9 years ago)

Author:

Henrik Bettermann

Message:

More docs.

Location:

main/waeup.kofa/trunk/docs/source/userdocs

Files:

• configuration.rst (modified) (1 diff)
• index.rst (modified) (1 diff)
• mandates.rst (added)
• students/browser.rst (modified) (4 diffs)
• testing.rst (modified) (4 diffs)

main/waeup.kofa/trunk/docs/source/userdocs/configuration.rst

@@ -1 +1 @@
 .. _configuration:
 
-Portal Configuration :sup:`in progress`
-***************************************
+Portal Configuration and Customization :sup:`in progress`
+*********************************************************

main/waeup.kofa/trunk/docs/source/userdocs/index.rst

@@ -17 +17 @@
    reports
    configuration
+   mandates
    testing
    buildingdocs

main/waeup.kofa/trunk/docs/source/userdocs/students/browser.rst

@@ -126 +126 @@
 
 
-Ticket Redemption
------------------
+Payment Ticket Redemption
+-------------------------
 
 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
@@ -157 +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``.
 
-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).
+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).
 
 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.
@@ -171 +171 @@
 =================================
 
-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>`
+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>`.
 
 .. seealso::
@@ -178 +178 @@
 
 
-.. _requesting_new_password:
-
-Requesting New Password
-=======================
-
-
-.. bed_tickets:
+.. _bed_tickets:
 
 Bed Tickets
 ===========
 
+Students can obtain a bed ticket if a series of conditions is met:
+
+- The current date must be inside the booking period (between `IHostelsContainer.startdate` and `IHostelsContainer.enddate`).
+
+- The student's current session must match the accommodation session (`IHostelsContainer.accommodation_session`).
+
+- A bed ticket for the same accommodation session does not exist.
+
+- The student must be in the correct workflow state (`IHostelsContainer.accommodation_states`).
+
+- A bed type, which fits to the student, can be determined.
+
+- A bed of that type is available.
+
+- The HOS activation code is not yet used.
+
+- The student is the owner of the activation code.
+
+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.
+
+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.
+
+
 Bed Relocation
 --------------
 
+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.
+
+.. seealso::
+
+  :ref:`Bed Space Booking Doctests <test_handle_accommodation>`
 
 

main/waeup.kofa/trunk/docs/source/userdocs/testing.rst

@@ -178 +178 @@
 
 The first test can be found in
-`waeup.kofa.browser.tests.test_browser.SupplementaryBrowserTests`:
-
-.. literalinclude:: ../../../src/waeup/kofa/browser/tests/test_browser.py
-   :pyobject: test_suspended_officer
-
-This test makes sure that a suspended officers can't login but see a
+`waeup.kofa.browser.tests.test_browser.SupplementaryBrowserTests`. The test makes sure that suspended officers can't login but see a
 proper warning message when trying to login. Furthermore, suspended
 officer accounts are clearly marked and a warning message shows up
@@ -189 +184 @@
 <officers>`.
 
+.. literalinclude:: ../../../src/waeup/kofa/browser/tests/test_browser.py
+   :pyobject: test_suspended_officer
+
 
 .. _test_handle_clearance:
 
-Handle Clearance by Clearance Officer
--------------------------------------
-
-This test can be found in
-`waeup.kofa.students.tests.test_browser.OfficerUITests`:
+Handling Clearance by Clearance Officer
+---------------------------------------
+
+This test can be found in
+`waeup.kofa.students.tests.test_browser.OfficerUITests`. The corresponding use
+case is partly described :ref:`elsewhere <rejecting_clearance>`.
 
 .. literalinclude:: ../../../src/waeup/kofa/students/tests/test_browser.py
@@ -204 +203 @@
 .. _test_handle_courses:
 
-Handle Course List Validation by Course Adviser
------------------------------------------------
-
-This test can be found in
-`waeup.kofa.students.tests.test_browser.OfficerUITests`:
+Handling Course List Validation by Course Adviser
+-------------------------------------------------
+
+This test can be found in
+`waeup.kofa.students.tests.test_browser.OfficerUITests`. The corresponding use
+case is described :ref:`elsewhere <course_registration>`.
 
 .. literalinclude:: ../../../src/waeup/kofa/students/tests/test_browser.py
@@ -220 +220 @@
 
 This test can be found in
-`waeup.kofa.students.tests.test_browser.OfficerUITests`:
+`waeup.kofa.students.tests.test_browser.OfficerUITests`. The corresponding use
+case is described :ref:`elsewhere <batch_editing_scores>`.
 
 .. literalinclude:: ../../../src/waeup/kofa/students/tests/test_browser.py
    :pyobject: test_handle_courses_by_lecturer
+
+
+.. _test_handle_accommodation:
+
+Bed Space Booking
+-----------------
+
+This test can be found in
+`waeup.kofa.students.tests.test_browser.OfficerUITests`. The corresponding use
+case is described :ref:`elsewhere <bed_tickets>`.
+
+.. literalinclude:: ../../../src/waeup/kofa/students/tests/test_browser.py
+   :pyobject: test_student_accommodation