Changeset 13088 for main/waeup.kofa/trunk/docs/source/userdocs/applicants

Timestamp:

21 Jun 2015, 15:11:15 (10 years ago)

Author:

Henrik Bettermann

Message:

Describe application workflow.

Location:

main/waeup.kofa/trunk/docs/source/userdocs/applicants

Files:

• interfaces.rst (modified) (1 diff)
• workflow.rst (modified) (1 diff)

main/waeup.kofa/trunk/docs/source/userdocs/applicants/interfaces.rst

@@ -62 +62 @@
 be moved from one container to another.**
 
+The application mode is either ``create`` or ``update``. In create
+mode, no record exists, the applicants container is empty. The records
+are being created after submission of the first form. Applicants are
+requested to provide all data needed, including their name details.
+In update mode, the applicants container must have been prefilled by
+import, e.g. with records provided by an external board. Applicants
+can't create new records, they can only open and take possession of
+existing records. Both methods have pros and cons. This is further
+discussed below.
+
 The application category is supplied by the
 `ApplicationCategorySource` (see `application categories of base

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

@@ -11 +11 @@
              |a
              |
-    +--+--- started ----------------------+--+
-    |  |     |                            |  |
-    |  |     |b                           |  |
-    |  |     |                            |  |
-    |  |h   paid                          |  |
-    |  |     |                           j|  |
-   i|  |     |c                           |  |
-    |  |     |                            |  |
-    |  +--- submitted ---------+          |  |k
-    |        |                 |          |  |
-    |        |d                |e         |  |
-    |        |        g        |          |  |
-    +----- admitted ----- not admitted ---+  |
-             |                               |
-             |f                              |
-             |                               |
-           created --------------------------+
+    +--+--- started ----------------------+
+    |  |     |                            |
+    |  |     |b                           |
+    |  |     |                            |
+    |  |h   paid                          |
+    |  |     |                            |
+   i|  |     |c                           |j
+    |  |     |                            |
+    |  +--- submitted ---------+          |
+    |        |                 |          |
+    |        |d                |e         |
+    |        |         g       |          |
+    +------ admitted ----- not admitted --+
+             |
+             |f
+             |
+           created
 
 
    a: start          -a: n/a
-   b: pay, approve   -b: reset6
-   c: submit         -c: reset5
+   b: pay, approve   -b: reset1
+   c: submit         -c: reset2
    d: admit          -d: n/a
    e: refuse1        -e: n/a
-   f: create         -f: reset7
+   f: create         -f: n/a
    g: refuse2        -g: n/a
-   h: n/a            -h: reset1
-   i: n/a            -i: reset2
-   j: n/a            -j: reset3
-   k: n/a            -k: reset4
+   h: n/a            -h: reset3
+   i: n/a            -i: reset4
+   j: n/a            -j: reset5
 
-
+Application starts with the creation of the applicant record, either
+by an anonymous user or by import. The first state is
+``initialized``. After first login, the state turns to ``started``
+**(a)**. Now the applicant is requested to fill the form, upload a
+passport picture and create a payment ticket. In contrast to student
+payments, making a payment and redeeming a payment is done in one
+step. Not only the ticket is marked ``paid``, but also the applicant
+is automatically set to state ``paid`` **(b)**. After successful
+payment the student can directly submit the application request
+**(c)**. Submitted records can be either sent back for editing and
+resubmission **(-c)**, accepted with admission confirmed **(d)** or
+accepted with admission refused **(e)**. Only application records
+with confirmed admission into the university can be transormed into
+student records. This final and **irreversible step** is accompanied
+by a transition to state ``created`` **(f)**.