1 | .. _registration_workflow: |
---|
2 | |
---|
3 | Registration Workflow |
---|
4 | ===================== |
---|
5 | |
---|
6 | Studying at a higher education institution means following |
---|
7 | orchestrated and repeatable patterns of activities or, in other |
---|
8 | words, following a workflow prescribed by the school regulations. |
---|
9 | This process starts with application for studying a programme |
---|
10 | offered by the school, and may end with de-registration of a |
---|
11 | student. But even after de-registration, former students can be kept |
---|
12 | in the system as alumni so that they can still access their records |
---|
13 | or can apply for official transcripts. |
---|
14 | |
---|
15 | Kofa divides these 'repeatable patterns of activities' into two |
---|
16 | different and strictly seperated workflows: an application and a |
---|
17 | student registration workflow. The latter, which presupposes the |
---|
18 | admission of the student, will be described here. |
---|
19 | |
---|
20 | A worflow defines states and transitions between the states. The |
---|
21 | following diagram shows the entire student registration workflow. |
---|
22 | Workflow states are connected with dashed lines which symbolize |
---|
23 | workflow transitions. There are no arrows at the end of each line |
---|
24 | because in most cases, Kofa provides transitions in both directions. |
---|
25 | Transitions are denoted by lower-case characters, reverse |
---|
26 | transitions additionally by a preceded dash. A few transitions do |
---|
27 | not 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 +---------------------------------+ |
---|
56 | b: start_clearance |
---|
57 | -b: reset2 |
---|
58 | c: request_clearance |
---|
59 | -c: reset3 (= reject request) |
---|
60 | d: clear |
---|
61 | -d: N/A |
---|
62 | e: N/A |
---|
63 | -e: reset4 (= annul clearance) |
---|
64 | f: pay_first_school_fee, approve_first_school_fee |
---|
65 | -f: reset5 (= annul payment) |
---|
66 | g: register_courses |
---|
67 | -g: reset7 (= reject request) |
---|
68 | h: pay_pg_fee, approve_pg_fee |
---|
69 | -h: N/A |
---|
70 | i: validate_courses |
---|
71 | -i: N/A |
---|
72 | j: bypass_validation |
---|
73 | -j: N/A |
---|
74 | k: return |
---|
75 | -k: reset9 |
---|
76 | l: pay_school_fee, approve_school_fee |
---|
77 | -l: reset6 (= annul payment) |
---|
78 | m: N/A |
---|
79 | -m: reset8 (= annul validation) |
---|
80 | n: N/A |
---|
81 | -n: N/A |
---|
82 | o: request_transcript |
---|
83 | -o: process_transcript |
---|
84 | |
---|
85 | |
---|
86 | Student registration starts with the first login of the student into |
---|
87 | state ``admitted``. After filling the email adress and phone number |
---|
88 | field, and also uploading a passport picture, the student |
---|
89 | immediately proceeds with the clearance sub-workflow. S/he starts |
---|
90 | clearance **(b)** either directly or by using a clearance access |
---|
91 | code, depending on the configuration of the portal. After filling |
---|
92 | the clearance form and uploading all necessary documents, the |
---|
93 | student requests clearance **(c)** which can be either accepted **(d)** |
---|
94 | or rejected **(-c)** by a clearance officer. A cleared student |
---|
95 | can enter the 'cyclical' part of the workflow which starts after |
---|
96 | first school fee payment **(f)**. |
---|
97 | |
---|
98 | A properly registering undergraduate student creates a new study |
---|
99 | level (course list) at the beginning of each academic session, adds |
---|
100 | the necessary course tickets and finally registers the list **(g)**. |
---|
101 | The student's course adviser subsequently validates the list **(i)**, |
---|
102 | or rejects the course registration request **(-g)** so that the |
---|
103 | student has to register again. Even after validation there is an |
---|
104 | option to annul the already validated course list **(-m)** so that |
---|
105 | the student can revise the list. At the end of the session, when all |
---|
106 | exams have been taken, course results (scores) are either entered by |
---|
107 | lecturers or imported by an import officer, a verdict is announced |
---|
108 | and the student is finally enabled to return **(k)**. In Kofa the |
---|
109 | last two steps are automatically performed by the Verdict Batch |
---|
110 | Processor. In some cases, course validators are not available or |
---|
111 | course validation is not necessary. Then validation can be skipped |
---|
112 | **(j)** by setting `bypass_validation` in the processor's import |
---|
113 | file to ``True``. In both cases the student arrives in state |
---|
114 | ``returning`` but is still in the same session. Also the current |
---|
115 | level has not changed. The new session starts only if the student |
---|
116 | pays school fee for the subsequent session **(l)**. Then |
---|
117 | `current_session` increases by one, `current_level` is set according |
---|
118 | to the verdict obtained, the old verdict is copied into |
---|
119 | `previous_verdict` and `current_verdict` is cleared. The student has |
---|
120 | arrived in the new academic session in state ``school_fee_paid``. |
---|
121 | The **gikl** cycle is repeatedly passed through till the student is |
---|
122 | ready for graduation. |
---|
123 | |
---|
124 | So far we have spoken about undergraduate students. The same |
---|
125 | sequence of transitions also applies to postgraduate students if |
---|
126 | they have to pass several levels (e.g. 700 and 800). Very often the |
---|
127 | level model does not apply to postgraduates. The students remain in |
---|
128 | the same (999) level but pay for each year of studying. In this case |
---|
129 | the **gikl** cycle collapses to the **h** cycle. Students may add |
---|
130 | course tickets whenever they like, but cannot register their course |
---|
131 | list. |
---|
132 | |
---|
133 | |
---|
134 | .. _workflow_batch_processing: |
---|
135 | |
---|
136 | Workflow Batch Processing |
---|
137 | ========================= |
---|
138 | |
---|
139 | The :py:class:`StudentProcessor |
---|
140 | <waeup.kofa.students.batching.StudentProcessor>` allows to import |
---|
141 | either workflow states or transitions. As already emphasized in the |
---|
142 | description of the processor class, we refer to them as unsafe and |
---|
143 | safe respectively. Transitions are only possible between allowed |
---|
144 | workflow states. Only transitions ensure that the registration |
---|
145 | workflow is maintained. Setting the workflow state by import is |
---|
146 | considered brute and must be avoided. |
---|
147 | |
---|
148 | |
---|
149 | .. _student_history: |
---|
150 | |
---|
151 | Student History |
---|
152 | =============== |
---|
153 | |
---|
154 | All transitions are automatically logged in ``students.log``. And |
---|
155 | also the import of workflow states is recorded in the logfile. |
---|
156 | However, these logfiles can only be accessed by some officers and |
---|
157 | are hidden from students. Since Kofa takes up the cause of |
---|
158 | transparancy, we were of the opinion, that also students must know, |
---|
159 | when and by whom the state of their record was changed. Therefore we |
---|
160 | store all workflow-relevant changes additionally in the student |
---|
161 | history which is attached to the student object. The history is a |
---|
162 | list of messages. Each message contains the local time, the workflow |
---|
163 | transition message and the public name of the user who triggered the |
---|
164 | transition, either online or by import:: |
---|
165 | |
---|
166 | 2015-05-16 05:11:34 UTC - Record created by System Admin |
---|
167 | 2015-05-30 07:34:09 UTC - Admitted by System Admin |
---|
168 | 2015-05-30 08:34:11 UTC - Clearance started by John Doe |
---|
169 | 2015-05-30 09:34:15 UTC - Clearance requested by John Doe |
---|
170 | 2015-05-30 10:37:27 UTC - Cleared by Clearance Officer |
---|
171 | |
---|
172 | If the workflow state is set by import, the following message would |
---|
173 | have been added instead:: |
---|
174 | |
---|
175 | 2015-05-30 10:37:27 UTC - State 'cleared' set by Import Officer |
---|
176 | |
---|
177 | Student histories are exportable but cannot be imported. |
---|