Changeset 13045


Ignore:
Timestamp:
13 Jun 2015, 22:03:06 (10 years ago)
Author:
Henrik Bettermann
Message:

More docs.

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

Legend:

Unmodified
Added
Removed

  • main/waeup.kofa/trunk/docs/source/userdocs/security.rst

    r12951 r13045  
    1010Kofa has a very efficient security machinery. The machinery does not
    1111perform authorization checks on the content objects themselves stored
    12 in the database but restricts the usage of views, i.e. web pages and
     12in the database, but, restricts the usage of views, i.e. web pages and
    1313forms which are needed to view or edit data. Views are protected by
    1414permissions the user must have to use the view. Instead of assigning
    … …  
    2323permission. Another example is the ManagePortal permission described
    2424below. The name of the permission may lead to believe that users can
    25 do everything with this permssions. This is not true. It does only
     25do everything with this permissions. This is not true. It does only
    2626give access to certain pages which are dedicated to portal managers
    2727and must not be accessed by any other user.

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

    r13042 r13045  
    6767When 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.
    6868
    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.
     69Finally, 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.
    7070
    7171.. important::
    … …  
    101101.. _payment_tickets:
    102102
    103 Payment Tickets
    104 ===============
     103Payments
     104========
    105105
    106106The `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.
    … …  
    121121
    122122Directly 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`).
     123: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`).
    124124
    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.
     125Until 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.
    126126
    127127Previous Session Payment Tickets
    … …  
    133133-----------------------
    134134
    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.
     135Balance 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
     137Course Registration
     138===================
     139
     140Study 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:
     141
     1421. :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
     1442. 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
     146In most cases, such an automatically created course list is not perfect or even ready for submission to the course adviser. The list has to 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
     148The 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
     150Editing Scores by Lecturers
     151===========================
     152
     153Requesting New Password
     154=======================
    136155
    137156Bed Tickets
    … …  
    141160--------------
    142161
    143 Course Tickets
    144 ==============
    145162
    146 Course Registration
    147 ===================
    148 
    149 Requesting a Password
    150 =====================
    151 
    152 Editing Scores by Lecturers
    153 ===========================
    154163
    155164.. _bootstrap: http://getbootstrap.com/
Note: See TracChangeset for help on using the changeset viewer.