Ignore:
Timestamp:
29 May 2015, 18:46:20 (10 years ago)
Author:
Henrik Bettermann
Message:

More docs.

File:
1 edited

Legend:

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

    r13005 r13023  
    172172-----------------------
    173173
    174 `waeup.kofa.students.interfaces.IStudentOnlinePayment` inherits from `waeup.kofa.payments.interfaces.IOnlinePayment` and has only two additional schema fields: `p_current` and `p_level` which are student-specific. It also promises three additional methods which
    175 
    176 
    177 xxxxxxxxxxxxxxxx
     174`waeup.kofa.students.interfaces.IStudentOnlinePayment` inherits from `waeup.kofa.payments.interfaces.IOnlinePayment` and has only two additional schema fields: `p_current` and `p_level` which are student-specific. It also promises three additional methods which process student data after successful or approved payment.
    178175
    179176.. literalinclude:: ../../../src/waeup/kofa/students/interfaces.py
     
    186183------------
    187184
     185A bed ticket confirms that a bed space in a hostel has been allocated to the student for the period of an academic session (`booking_session`). The `bed_coordinates` specify which bed space has been booked. Sometimes this value is too cryptic and inappropriate to guide the student to the bed space. The `display_coordinates` property can be used to 'translate' the coordinates and display a customary description of the bed space. Much like some study level attributes, also `display_coordinates` is defined as a read-only schema field in order to automatically display the field on form pages. It is excluded by the `attrs_to_fields` function and thus not stored in the database.
     186
    188187.. literalinclude:: ../../../src/waeup/kofa/students/interfaces.py
    189188   :pyobject: IBedTicket
    190 
    191189
    192190Registration Workflow
    193191=====================
    194192
     193Studying at a higher education institution means following orchestrated and repeatable patterns of activities or, in other words, following a workflow prescribed by the school regulations. This process starts with application for studying a programme offered by the school, and may end with de-registration of a student. But even after de-registration, former students can be kept in the system as alumni so that they can still access their records or can apply for official transcripts.
     194
     195Kofa divides these 'repeatable patterns of activities' into two different and strictly seperated workflows: an application and a student registration workflow. The latter, which presupposes the admission of the student, will be described here.
     196
     197A worflow defines states and transitions between the states. The following diagram shows the entire student registration workflow. Workflow states are connected with dashed lines which symbolize workflow transitions. There are no arrows at the end of each line because in most cases, Kofa provides transitions in both directions. Transitions are denoted by lower-case characters, reverse transitions additionally by a preceded dash. A few transitions do not make sense and are thus not available (N/A)::
     198
     199              a
     200   created ------- admitted
     201              b       |
     202     +----------------+
     203     |                         e
     204     +------------------------------------------------------+
     205     |                  c                            d      |
     206   clearance started ------- clearance requested  ------- cleared
     207                                                            |
     208                                f                           |
     209     +--------+---------------------------------------------+
     210     |        |
     211     | h    school fee paid -------- returning -------------+
     212     |        |             \   l        |                  |
     213     +--------+ g            \ _ _ _ m   | k                |
     214              |                      \   |                  |
     215           courses registered ------ courses validated      |
     216                          |      i       |                  |
     217                          |              | n                |
     218                          | j            |                  |
     219                          |          graduated              |
     220                          |              |                  |
     221                          |              | o                |
     222                          |              |                  |
     223                          |          transcript requested   |
     224     a: admit             |                                 |
     225    -a: reset1            +---------------------------------+
     226     b: start_clearance
     227    -b: reset2
     228     c: request_clearance
     229    -c: reset3 (= reject request)
     230     d: clear
     231    -d: N/A
     232     e: N/A
     233    -e: reset4 (= annul clearance)
     234     f: pay_first_school_fee, approve_first_school_fee
     235    -f: reset5 (= annul payment)
     236     g: register_courses
     237    -g: reset7 (= reject request)
     238     h: pay_pg_fee, approve_pg_fee
     239    -h: N/A
     240     i: validate_courses
     241    -i: N/A
     242     j: bypass_validation
     243    -j: N/A
     244     k: return
     245    -k: reset9
     246     l: pay_school_fee, approve_school_fee
     247    -l: reset6 (= annul payment)
     248     m: N/A
     249    -m: reset8 (= annul validation)
     250     n: N/A
     251    -n: N/A
     252     o: request_transcript
     253    -o: process_transcript
     254
     255
     256Student registration starts with the first login of the student into state ``admitted``. After filling the email adress and phone number field, and also uploading a passport picture, the student immediately proceeds with the clearance sub-workflow. S/he starts clearance (**b**) either directly or by using a clearance activation code, depending on the configuration of the portal. After filling the clearance form and uploading all necessary documents, the student requests clearance (**c**) which can be either accepted (**d**) or rejected (**-c**) by a clearance officer. A cleared student can enter the 'cyclical' part of the workflow which starts after first school fee payment (**f**).
     257
     258A properly registering undergraduate student creates a new study level (course list) at the beginning of each academic session, adds the necessary course tickets and finally registers the list (**g**). The student's course adviser subsequently validates the list (**i**). At the end of the session, when all exams have been taken, course results (scores) are either entered by lecturers or imported by an import officer, a verdict is announced and the student is finally enabled to return (**k**). In Kofa the last two steps are automatically performed by the Verdict Batch Processor. The student is now in state ``returning`` but still in the same session. Also the current level has not changed. The new academic year starts only if the student the pays school fee for the subsequent session (**l**). `current_session` increases by one, `current_level` is set according to the verdict obtained, the old verdict is copied into `previous_verdict` and `current_verdict` is cleared. The student has arrived in the new academic session in state ``school_fee_paid``. This ccle is repeatedly passed through till the student is ready for graduation.
     259
     260
    195261Browser Pages
    196262=============
Note: See TracChangeset for help on using the changeset viewer.