source: main/waeup.kofa/trunk/docs/source/userdocs/applicants/workflow.rst

Last change on this file was 15875, checked in by Henrik Bettermann, 5 years ago

Add application worklfow transition reset6.

File size: 3.5 KB
Line 
1.. _application_workflow:
2
3Application Workflow
4====================
5
6For an introduction see :ref:`registration_workflow`. The already
7mentioned application workflow is shown here::
8
9            initialized
10             |
11             |a
12             |
13    +--+--- started ----------------------+
14    |  |     |                            |
15    |  |     |b                           |
16    |  |     |                            |
17    |  |h   paid   +-- processed          |
18    |  |     |     |                      |
19   i|  |     |c    |k                     |
20    |  |     |     |                      |
21    |  +--- submitted ---------+          |
22    |        |                 |          |
23    |        |d                |e         |
24    |        |         g       |          |
25    +------ admitted ----- not admitted --+
26             |
27             |f
28             |
29            created
30
31
32   a: start          -a: n/a
33   b: pay, approve   -b: reset1
34   c: submit         -c: reset2
35   d: admit          -d: n/a
36   e: refuse1        -e: n/a
37   f: create         -f: n/a
38   g: refuse2        -g: n/a
39   h: n/a            -h: reset3
40   i: n/a            -i: reset4
41   j: n/a            -j: reset5
42   k: process        -k: reset6
43
44Application starts with the creation of the applicant record, either
45by an anonymous user or by import. The first state is
46``initialized``. After first login, the state turns to ``started``
47**(a)**. Now the applicant is requested to fill the form, upload a
48passport picture and create a payment ticket. In contrast to student
49payments, making a payment and redeeming a payment is done in one
50step. Not only the ticket is marked ``paid``, but also the applicant
51is automatically set to state ``paid`` **(b)**. After successful
52payment the student can directly submit the application request
53**(c)**. Submitted records can be either sent back for editing and
54resubmission **(-c)**, accepted with admission confirmed **(d)** or
55accepted with admission refused **(e)**. Only applicant records
56with confirmed admission into the university can be transormed into
57student records. This final and **irreversible step** is accompanied
58by a transition to state ``created`` **(f)**.
59
60Submitted records can also be marked ``processed`` **(k)** in case
61the application module is used for other kinds of application
62processes which have nothing to do with student admission, e.g.
63transcript application or late payments by alumni.
64
65
66.. _application_history:
67
68Application History
69===================
70
71All transitions are automatically logged in ``applicants.log`` and the
72applicant's history. And also the import of workflow states is
73recorded in the logfile and the history, see :ref:`student_history`
74for further information. This is a sample history of an applicant
75which passes through the application process without any
76complications::
77
78  2015-06-23 08:56:23 UTC - Application initialized by Anonymous
79  2015-06-23 08:57:42 UTC - Application started by Demo Applicant
80  2015-06-23 08:59:41 UTC - Payment approved by Benny Goodman
81  2015-06-23 09:00:50 UTC - Application submitted by Demo Applicant
82  2015-06-23 09:01:13 UTC - Applicant admitted by Benny Goodman
83  2015-06-23 09:02:36 UTC - Student record created (K1000003) by Benny Goodman
84
85Benny Goodman is the name of an applications manager. If the
86workflow state is set by him by import, the following message would
87have been added instead::
88
89  2015-06-23 09:01:13 UTC - State 'admitted' set by Benny Goodman
90
91Applicant histories are exportable but cannot be imported.
Note: See TracBrowser for help on using the repository browser.