Ignore:
Timestamp:
15 Jun 2015, 09:14:47 (10 years ago)
Author:
Henrik Bettermann
Message:

Insert line breaks.

Location:
main/waeup.kofa/trunk/docs/source/userdocs
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • main/waeup.kofa/trunk/docs/source/userdocs/students.rst

    r13025 r13048  
    6464   students/workflow
    6565
    66 Browser Pages  :sup:`in progress`
    67 =================================
     66Browser Pages
     67=============
    6868
    6969.. toctree::
  • main/waeup.kofa/trunk/docs/source/userdocs/students/browser.rst

    r13047 r13048  
    44============================
    55
    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.
     6The reader may ask: How do officers and students browse the portal?
     7Where are the step-by-step operating instructions on how to use
     8Kofa? We are always tempted to answer: The menu navigation should be
     9self-explanatory and it's quite easy to follow the menu prompts or
     10flash messages which appear above page titles in a green, yellow or
     11red box. For the students section this answer seems a bit over the
     12top. We must indeed describe some browser pages and what their
     13clickable actions are doing with the data. The reason is, that a lot
     14of Kofa's functionality is embedded in view and utility methods and
     15not only provided by the functionality of content components as
     16described above.
    717
    818
     
    1222===========
    1323
    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.
     24Kofa makes use of two different `Bootstrap`_ layouts. Anonymous
     25users, students and applicants do see a single-column theme with
     26only a static top navigation bar. Students can navigate to the
     27various display pages of their record by pulling down the 'My Data'
     28in the navigation bar.
     29
     30Officers see a double-column theme after logging in. The left column
     31contains a box which contains links to the user's preferences (My
     32Preferences) and roles (My Roles). It also contains links to the
     33various sections of Kofa depending on the permissions the officer
     34has has obtained. Possible sections are: 'Portal Configuration',
     35'Officers', 'Data Center', 'Reports' and 'Access Codes'. A second
     36box shows up in the left column when the officer accesses a student
     37record. This box gives direct access to the display pages of a
     38student record.
    1739
    1840
     
    2244=====================
    2345
    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.
     46Pages, 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
     48reader respectively. Views are dealing with request and response
     49objects. In Kofa most pages are form pages which means they are
     50views on data. These pages are either used to display, edit or add
     51persistant data. Thus we can further distinguish display, edit and
     52add form pages. Kofa is using the `Zope Formlib`_ package to
     53auto-generate these forms.
    2554
    2655.. note::
    2756
    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
     64Whereas display and add form pages are usually shared by officers
     65and students, edit form pages are not. Students are not allowed to
     66edit all of their data all the time. Edit access is restricted by
     67workflow states or other conditions. Officers' access is much less
     68restricted and we therefore speak of 'managing' instead of 'editing'
     69data. In most cases, Kofa uses two different form pages which
     70require different permissions: An `EditFormPage` requires the
     71:py:class:`HandleStudent<waeup.kofa.students.permissions.HandleStudent>`
     72permission and a `ManageFormPage` requires the
     73:py:class:`ManageStudent<waeup.kofa.students.permissions.ManageStudent>`
     74permission.
    3175
    3276
     
    57101=====================
    58102
    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.
     103Officers with
     104:py:class:`LoginAsStudent<waeup.kofa.students.permissions.LoginAsStudent>`
     105permission do see a 'Login as student' button on student display
     106pages which redirects to a page, where a temporary student password
     107can be set by clicking a 'Set password now' form button. The
     108temporary password is valid for 10 minutes. During this period the
     109student can't login. The officer is being redirected to a login page
     110which allows to directly login as student with pre-filled temporary
     111credentials. The second page is to avoid that officers must remember
     112the student credentials, have to logout from their own account and
     113manually login as student via the regular login page. After 10
     114minutes the officer is automatically thrown out and the student is
     115able to login again (if the officer hasn't changed the password).
     116Attention: When logging in as student, the officer really
     117impersonates the student. All actions are logged with the student id
     118and not with the officer's user id. However, start of student
     119impersonation is also logged, so that officers can be identified and
     120fraudulent use can be discovered.
    60121
    61122
     
    65126===================
    66127
    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.
     128When a clearance officer clicks the 'Save comment and reject
     129clearance now' button, the `reject` action method of the
     130:py:class:`StudentRejectClearancePage<waeup.kofa.students.browser.StudentRejectClearancePage>`
     131is called. This method first checks, in which workflow state the
     132student is, and fires a transition accordingly. Then the comment,
     133which should explain why the request was requested, is saved twice
     134in the `officer_comment` attribute of the student and in
     135``students.log``. As soon as the `clear` transition (d) is effected,
     136an event handler clears the attribute again. The logfile message is
     137permanent and ensures that the original cause of rejection can
     138always be reconstructed.
     139
     140Finally, the method redirects to the ContactStudentForm and prefills
     141the HTML form with the comment previously saved. The clearance
     142officer can leave the comment as it is, or can modify the text to
     143give more information about the reason of rejection. This comment
     144will then be sent to the student by email. This comment is not saved,
     145neither in the student object nor in the logfile.
    70146
    71147.. important::
    72148
    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.
    74154
    75155.. seealso::
     
    83163================
    84164
    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.
     165Transferring a student means enabling the student to study another
     166programme.
     167
     168The simple but dirty way is to select another certificate and adjust
     169study course attributes accordingly. Existing study levels can be
     170either removed or, in case registered courses can be credited, left
     171as they are. This simple way is tedious and also dangerous, because
     172changes are not tracable. Only the logfile can tell us, that an
     173officer has edited the student's data. The data of the previous
     174study course are not backed up. They are lost.
     175
     176Kofa provides a more adequate, cleaner and tracable way of
     177transferring students. It can make a backup of the entire study
     178course container and create a new and empty container for the new
     179study programme with only one click or even by batch processing.
     180
     181After clicking the 'Transfer student' button the
     182`StudentTransferFormPage` opens and asks for the new certificate,
     183current session, current level and current verdict. After submitting
     184this form, the student transfer method checks if the old study
     185course is complete and ready for transfer. It also checks if the
     186number of possible transfers is not exceeded. Kofa allows two (2)
     187transfers! Finally the copying process is started and history and
     188logfile messages are added.
     189
     190The old study course container(s) can still be accessed via links on
     191the current study course display page. But, they can neither be
     192edited, removed, exported or reimported.
    94193
    95194
     
    97196---------------------------
    98197
    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``.
     198Sometimes students of an entire study programme have to be
     199transferred to another programme. This can be done with the
     200:py:class:`StudentStudyCourseProcessor<waeup.kofa.students.batching.StudentStudyCourseProcessor>`.
     201The 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
     204transfer is automatically initialized if the `entry_mode` value is
     205``transfer``.
    100206
    101207
     
    103209----------------------------
    104210
    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.
     211Previous transfers can be reverted by opening the previous study
     212course and clicking the 'Reactivate this study course (revert
     213previous transfer)' button. This is a complete rollback of the last
     214transfer. The current study mode will be irrevocably deleted and
     215replaced by the previous study course. The second last study course
     216will become the previous study course.
    106217
    107218
     
    111222========
    112223
    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.
     224The `PaymentsManageFormPage` is used by both students and students
     225officers. The page tabulates existing payment tickets and allows to
     226add or remove tickets. Officers can remove all payment tickets,
     227students only those without a response code (`r_code`). Attention:
     228Students can remove tickets without response code even if they have
     229been marked paid.
     230
     231There are three different add form pages to add
     232`StudentOnlinePayment` instances (= payment tickets). They all
     233create objects of the same type, only their attributes are set
     234differently.
    116235
    117236
     
    119238-------------------------------
    120239
    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`).
     240Current session payments are the regular payments which have to be
     241made in each session to proceed to the next registration step. The
     242add form provides a select box of available payment categories
     243(`p_category`). After submitting the form, Kofa determines the total
     244amount and sets attributes like payment item (`p_item`), payment
     245session (`p_session`) and payment level (`p_level`) automatically.
     246The Boolean `p_current` attribute is set ``True``. The creation
     247datetime is stored in the `creation_date` attribute and is also used
     248to construct the unique payment id (`p_id`).
    122249
    123250.. note::
    124251
    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.
    126257
    127258
     
    129260-------------------------
    130261
    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.
     262Directly after a student payment ticket has been paid - either by
     263approval by an officer or by receiving a positive response from a
     264payment gateway - the
     265:py:meth:`redeemTicket<waeup.kofa.students.payments.StudentOnlinePayment.redeemTicket>`
     266method is called. Depending on the category of the payment, an
     267appropriate access or activation code is beeing created for the
     268owner of the ticket. This code must be entered on certain form pages
     269to activate the paid service or to access the next stage of the
     270registration process. In other words, making a payment and redeeming
     271a payment are two different steps. Successful payments do not
     272automatically trigger any action in the portal but create a specifc
     273access code which can be used to trigger access-code-related actions
     274(see :ref:`accesscodes`).
     275
     276Until May 2015 also school fee payments had produced access codes,
     277which enabled students to start the next session. Since software
     278revision 12889, Kofa bypasses SFE access code creation and starts
     279the next session automatically.
    135280
    136281
     
    138283--------------------------------
    139284
    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.
     285Previous session payments are additional payments which do not
     286induce further actions in Kofa. Their sole purpose is to enable
     287students to pay for services in previous sessions which they missed
     288to pay. The add form for previous session payments allows the
     289student to select the payment category, session and level by
     290him/herself.
    141291
    142292
     
    144294-----------------------
    145295
    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.
     296Balance payments have been introduced to correct previously made
     297payments. In some cases, students select the wrong payment category,
     298or other things may have happened which led students pay less than
     299expected. This can be balanced by paying a differential amount.
     300Therefore, the add form for balance payments allows to freely choose
     301the total amount to be paid. It also asks for the category, the
     302session and the level the payment is meant for. Like previous
     303session payments, balance payments do not induce further actions in
     304Kofa. Both can be omitted in customized versions of Kofa if these
     305features are not needed.
    147306
    148307.. _course_registration:
     
    151310===================
    152311
    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.
     312Study levels are pre-filled with course tickets. When adding a study
     313level,
     314:py:meth:`StudentStudyCourse.addStudentStudyLevel<waeup.kofa.students.studycourse.StudentStudyCourse.addStudentStudyLevel>`
     315automatically adds course tickets in two steps:
     316
     3171.  :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
     3262.  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
     334In most cases such an automatically created course list is not
     335perfect or even ready for submission to the course adviser. The list
     336must be edited according to the student's needs. Students can select
     337further courses, which they desire to attend, and can create
     338additional course tickets, as long as the total number of credits do
     339not exceed 50 (value customizable). Course tickets can also be
     340removed. Whereas officers can remove any ticket from the list,
     341students can remove only optional (non-mandatory) course tickets
     342(condition customizable).
     343
     344The edit form page provides a 'Register course list' button which
     345submits the course list to the course adviser for validation. Course
     346advisers can't edit the registered/submitted course list, but they
     347can validate or reject it by pressing the same-named link buttons.
     348After pressing the 'Reject courses' button, Kofa redirects to the
     349ContactStudentForm which can be used to inform the student about the
     350reason of rejection. In contrast to clearance rejection, the message,
     351which is being sent to the student by email, is neither stored in
     352the database nor in the logfiles.
    162353
    163354.. seealso::
     
    171362=================================
    172363
    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>`.
     364Lecturers cannot access student records directly. They don't have
     365access to the student section. Instead, lecturers go to their course
     366in the academic section and view or export lists of students who
     367attended the course, either in a previous or in the current session.
     368They 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
     372the portal's configuration page. The `EditScoresPage` lists all
     373students, who are attending the course in the current academic
     374session. Score editing is allowed if the student's current session
     375corresponds with the current academic session and the student is in
     376state 'courses validated', see method
     377:py:meth:`CourseTicket.editable_by_lecturer<waeup.kofa.students.studylevel.CourseTicket.editable_by_lecturer>`.
    174378
    175379.. seealso::
     
    185389Students can obtain a bed ticket if a series of conditions is met:
    186390
    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`).
    190396
    191397- A bed ticket for the same accommodation session does not exist.
    192398
    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`).
    194401
    195402- A bed type, which fits to the student, can be determined.
     
    201408- The student is the owner of the activation code.
    202409
    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.
     410The customizable utility method
     411:py:meth:`getAccommodationDetails<waeup.kofa.students.utils.StudentsUtils.getAccommodationDetails>`
     412composes a bed type string. Three criteria are checked: Is the
     413student a new, a returning or a final year student? Is the student
     414female or male? Has the student to be accommodated in a special
     415hostel (`IHostel.special_handling`)? The resulting bed type string
     416contains these information. Example: ``regular_female_fr`` means
     417that a bed for a new female student in a regular hostel is wanted.
     418If the student record allows to determine such a bed string, Kofa
     419starts searching a proper bed space.
     420
     421Before Kofa searches for a free bed space, which meets the bed type
     422criteria above, it checks if a bed space has already been allocated
     423manually to the student. If so, then this bed is used, no matter
     424whether the bed meets the criteria or not. (Theoretically, a male
     425student can be accommodated in a hostel which is reserved for female
     426students.) If no manually allocated bed space is found, Kofa
     427searches for the right space. If bed booking is subject to a charge,
     428Kofa also checks, if the student has entered a valid activation code,
     429before delivering the bed coordinates to the student.
    206430
    207431
     
    209433--------------
    210434
    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.
     435Officers with `ManageHostels` permission do see a 'Relocate student'
     436link button which calls the `BedTicketRelocationPage`. This view
     437relocates the student if student parameters or the bed type of the
     438bed have changed. The `update` method of this view checks first, if
     439the student has a 'reserved' bed space. Students in reserved beds
     440are never subject to relocation. It checks secondly, if booking has
     441been cancelled in the accommodation section but other bed space has
     442been manually allocated after cancellation. Then this bed is used,
     443no matter whether the bed meets the bed type criteria or not. If
     444both checks are negative, Kofa searches for a free bed space, which
     445meets the student's bed type criteria. Only if it finds a new and
     446free bed space, it starts the relocation process by releasing the
     447old bed, booking the new bed and designating the new bed in the bed
     448ticket.
    212449
    213450.. seealso::
Note: See TracChangeset for help on using the changeset viewer.