source: main/waeup.kofa/trunk/docs/source/userdocs/students/workflow.rst @ 15334

Last change on this file since 15334 was 15334, checked in by Henrik Bettermann, 6 years ago

Add tests and adjust the documentation.

File size: 9.7 KB
Line 
1.. _registration_workflow:
2
3Registration Workflow
4=====================
5
6Studying at a higher education institution means following
7orchestrated and repeatable patterns of activities or, in other
8words, following a process workflow prescribed by the school
9regulations. This process starts with application for studying a
10programme offered by the school, and may end with de-registration of
11a student. But even after de-registration, former students can be
12kept in the system as alumni so that they can still access their
13records or can apply for official transcripts.
14
15Kofa divides these 'repeatable patterns of activities' into two
16different and strictly seperated process workflows: an application
17and a student registration workflow. The latter, which presupposes
18the admission of the student, will be described here.
19
20A worflow defines states and transitions between the states. The
21following diagram shows the entire student registration workflow.
22Workflow states are connected with dashed lines which symbolize
23workflow transitions. There are no arrows at the end of each line
24because in most cases, Kofa provides transitions in both directions.
25Transitions are denoted by lower-case characters, reverse
26transitions additionally by a preceded dash. A few transitions do
27not make sense and are thus not available (N/A)::
28
29              a
30    created ------- admitted
31               b       |
32      +----------------+
33      |                         e
34      +------------------------------------------------------+
35      |                  c                            d      |
36    clearance started ------- clearance requested  ------- cleared
37                                                             |
38                                 f                           |
39      +--------+---------------------------------------------+
40      |        |
41      | h    school fee paid -------- returning -------------+
42      |        |             \   l        |                  |
43      +--------+ g            \ _ _ _ m   | k                |
44               |                      \   |                  |
45            courses registered ------ courses validated      |
46                           |      i       |                  |
47                           |              | n                |
48                           | j            |                  |
49                           |      +-- graduated              |
50                           |      |       |                  |
51                           |      |       | o                |
52                           |      |       |                  |
53                           |      |   transcript requested   |
54     a: admit              |      |       |                  |
55    -a: reset1             |    r |       | p                |
56     b: start_clearance    |      |       |                  |
57    -b: reset2             |      |   transcript validated   |
58     c: request_clearance  |      |       |                  |
59    -c: reset3             |      |       | q                |
60        (= reject request) |      |       |                  |
61     d: clear              |      +-- transcript released    |
62    -d: N/A                +---------------------------------+
63     e: N/A
64    -e: reset4 (= annul clearance)
65     f: pay_first_school_fee, approve_first_school_fee
66    -f: reset5 (= annul payment)
67     g: register_courses
68    -g: reset7 (= unregister)
69     h: pay_pg_fee, approve_pg_fee
70    -h: N/A
71     i: validate_courses
72    -i: N/A
73     j: bypass_validation
74    -j: N/A
75     k: return
76    -k: reset9
77     l: pay_school_fee, approve_school_fee
78    -l: reset6 (= annul payment)
79     m: N/A
80    -m: reset8 (= annul validation)
81     n: N/A
82    -n: N/A
83     o: request_transcript
84    -o: reset10 (= reject request)
85     p: validate_transcript
86    -p: N/A
87     q: release_transcript
88    -q: N/A
89     r: N/A
90    -r: reset11
91
92Student registration starts with the first login of the student into
93state ``admitted``. After filling the email adress and phone number
94field, and also uploading a passport picture, the student
95immediately proceeds with the clearance sub-workflow. S/he starts
96clearance **(b)** either directly or by using a clearance access
97code, depending on the configuration of the portal. After filling
98the clearance form and uploading all necessary documents, the
99student requests clearance **(c)** which can be either accepted **(d)**
100or rejected **(-c)** by a clearance officer. A cleared student
101can enter the 'cyclical' part of the workflow which starts after
102first school fee payment **(f)**.
103
104A properly registering undergraduate student creates a new study
105level (course list) at the beginning of each academic session, adds
106the necessary course tickets and finally registers the list **(g)**.
107The student's course adviser subsequently validates the list **(i)**,
108or rejects the course registration request **(-g)** so that the
109student has to register again. Even after validation there is an
110option to annul the already validated course list **(-m)** so that
111the student can revise the list. At the end of the session, when all
112exams have been taken, course results (scores) are either entered by
113lecturers or imported by an import officer, a verdict is announced
114and the student is finally enabled to return **(k)**. In Kofa the
115last two steps are automatically performed by the Verdict Batch
116Processor. In some cases, course validators are not available or
117course validation is not necessary. Then validation can be skipped
118**(j)** by setting `bypass_validation` in the processor's import
119file to ``True``. In both cases the student arrives in state
120``returning`` but is still in the same session. Also the current
121level has not changed. The new session starts only if the student
122pays school fee for the subsequent session **(l)**. Then
123`current_session` increases by one, `current_level` is set according
124to the verdict obtained, the old verdict is copied into
125`previous_verdict` and `current_verdict` is cleared. The student has
126arrived in the new academic session in state ``school_fee_paid``.
127The **gikl** cycle is repeatedly passed through till the student is
128ready for graduation.
129
130So far we have spoken about undergraduate students. The same
131sequence of transitions also applies to postgraduate students if
132they have to pass several levels (e.g. 700 and 800). Very often the
133level model does not apply to postgraduates. The students remain in
134the same (999) level but pay for each year of studying. In this case
135the **gikl** cycle collapses to the **h** cycle. Students may add
136course tickets whenever they like, but cannot register their course
137list.
138
139After graduation, former students (alumni) can apply for an official
140transcript. The transcript processing workflow (**opqr**) is a
141subset of the registration workflow which starts in state
142``graduated``. Many people are involved in transcript processing.
143Therefore, Kofa provides two additional roles, the Transcript
144Officer and Transcript Signee roles. Both are available globally and
145locally (at faculty level). First of all, the graduated student has
146to request a transcript **(o)** by filling a request form. The
147Transcript Officer will see the new request and can either reject
148the request **(-o)** or validate the request **(p)**. Before
149validation course results can be edited or added by a Students
150Manager, transcript study level remarks also by Transcript Officers.
151After validation the entire studycourse including its content is
152locked. Nobody will be able to modify the course lists, neither
153through the UI nor by import. Transcripts can now be electronically
154signed by Transcript Signees. Once all signees have done their job,
155the Transcript Officer can release the transcript **(q)**. A pdf
156file is created and stored in the file system. The transcript pdf
157slip contains all signatures. The dynamic transcript generation is
158disabled. Nothing can be changed now, unless the entire transcript
159process is reset **(-r)** by a Students Manager. Then comments and
160signatures will be removed and the pdf file deleted. The student can
161start afresh.
162
163.. _registration_workflow_batch_processing:
164
165Workflow Batch Processing
166=========================
167
168The :py:class:`StudentProcessor
169<waeup.kofa.students.batching.StudentProcessor>` allows to import
170either workflow states or transitions. As already emphasized in the
171description of the processor class, we refer to them as unsafe and
172safe respectively. Transitions are only possible between allowed
173workflow states. Only transitions ensure that the registration
174workflow is maintained. Setting the workflow state by import is
175considered brute and must be avoided.
176
177
178.. _student_history:
179
180Student History
181===============
182
183All transitions are automatically logged in ``students.log``. And
184also the import of workflow states is recorded in the logfile.
185However, these logfiles can only be accessed by some officers and
186are hidden from students. Since Kofa takes up the cause of
187transparancy, we are of the opinion, that also students must know,
188when and by whom the state of their record was changed. Therefore we
189store all workflow-relevant changes additionally in the student
190history which is attached to the student object. The history is a
191list of messages. Each message contains the local time, the workflow
192transition message and the public name of the user who triggered the
193transition, either online or by import::
194
195  2015-05-16 05:11:34 UTC - Record created by System Admin
196  2015-05-30 07:34:09 UTC - Admitted by System Admin
197  2015-05-30 08:34:11 UTC - Clearance started by John Doe
198  2015-05-30 09:34:15 UTC - Clearance requested by John Doe
199  2015-05-30 10:37:27 UTC - Cleared by Clearance Officer
200
201If the workflow state is set by import, the following message would
202have been added instead::
203
204  2015-05-30 10:37:27 UTC - State 'cleared' set by Import Officer
205
206Student histories are exportable but cannot be imported.
Note: See TracBrowser for help on using the repository browser.