| 1 | .. _application_workflow: |
|---|
| 2 | |
|---|
| 3 | Application Workflow |
|---|
| 4 | ==================== |
|---|
| 5 | |
|---|
| 6 | For an introduction see :ref:`registration_workflow`. The already |
|---|
| 7 | mentioned application workflow is shown here:: |
|---|
| 8 | |
|---|
| 9 | initialized |
|---|
| 10 | | |
|---|
| 11 | |a |
|---|
| 12 | | |
|---|
| 13 | +--+--- started ----------------------+ |
|---|
| 14 | | | | | |
|---|
| 15 | | | |b | |
|---|
| 16 | | | | | |
|---|
| 17 | | |h paid | |
|---|
| 18 | | | | | |
|---|
| 19 | i| | |c |j |
|---|
| 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 | |
|---|
| 43 | Application starts with the creation of the applicant record, either |
|---|
| 44 | by an anonymous user or by import. The first state is |
|---|
| 45 | ``initialized``. After first login, the state turns to ``started`` |
|---|
| 46 | **(a)**. Now the applicant is requested to fill the form, upload a |
|---|
| 47 | passport picture and create a payment ticket. In contrast to student |
|---|
| 48 | payments, making a payment and redeeming a payment is done in one |
|---|
| 49 | step. Not only the ticket is marked ``paid``, but also the applicant |
|---|
| 50 | is automatically set to state ``paid`` **(b)**. After successful |
|---|
| 51 | payment the student can directly submit the application request |
|---|
| 52 | **(c)**. Submitted records can be either sent back for editing and |
|---|
| 53 | resubmission **(-c)**, accepted with admission confirmed **(d)** or |
|---|
| 54 | accepted with admission refused **(e)**. Only application records |
|---|
| 55 | with confirmed admission into the university can be transormed into |
|---|
| 56 | student records. This final and **irreversible step** is accompanied |
|---|
| 57 | by a transition to state ``created`` **(f)**. |
|---|
| 58 | |
|---|
| 59 | |
|---|
| 60 | .. _application_history: |
|---|
| 61 | |
|---|
| 62 | Application History |
|---|
| 63 | =================== |
|---|
| 64 | |
|---|
| 65 | All transitions are automatically logged in applicants.log and the applicant's history. And also the import of workflow states is recorded in the logfile and the history, see :ref:`student_history` for further information. This is a sample history of an applicant which passes through the application process without any complications:: |
|---|
| 66 | |
|---|
| 67 | 2015-06-23 08:56:23 UTC - Application initialized by Anonymous |
|---|
| 68 | 2015-06-23 08:57:42 UTC - Application started by Demo Applicant |
|---|
| 69 | 2015-06-23 08:59:41 UTC - Payment approved by Benny Goodman |
|---|
| 70 | 2015-06-23 09:00:50 UTC - Application submitted by Demo Applicant |
|---|
| 71 | 2015-06-23 09:01:13 UTC - Applicant admitted by Benny Goodman |
|---|
| 72 | 2015-06-23 09:02:36 UTC - Student record created (K1000003) by Benny Goodman |
|---|
| 73 | |
|---|
| 74 | Benny Goodman is the name of an applications manager. If the workflow state is set by import, the following message would |
|---|
| 75 | have been added instead:: |
|---|
| 76 | |
|---|
| 77 | 2015-06-23 09:01:13 UTC - State 'admitted' set by Benny Goodman |
|---|
| 78 | |
|---|
| 79 | Applicant histories are exportable but cannot be imported. |
|---|
