Ignore:
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:
2 edited

Legend:

Unmodified
Added
Removed
  • main/waeup.kofa/trunk/docs/source/userdocs/applicants/interfaces.rst

    r13082 r13088  
    6262be moved from one container to another.**
    6363
     64The application mode is either ``create`` or ``update``. In create
     65mode, no record exists, the applicants container is empty. The records
     66are being created after submission of the first form. Applicants are
     67requested to provide all data needed, including their name details.
     68In update mode, the applicants container must have been prefilled by
     69import, e.g. with records provided by an external board. Applicants
     70can't create new records, they can only open and take possession of
     71existing records. Both methods have pros and cons. This is further
     72discussed below.
     73
    6474The application category is supplied by the
    6575`ApplicationCategorySource` (see `application categories of base
  • main/waeup.kofa/trunk/docs/source/userdocs/applicants/workflow.rst

    r13083 r13088  
    1111             |a
    1212             |
    13     +--+--- started ----------------------+--+
    14     |  |     |                            |  |
    15     |  |     |b                           |  |
    16     |  |     |                            |  |
    17     |  |h   paid                          |  |
    18     |  |     |                           j| |
    19    i|  |     |c                           |  |
    20     |  |     |                            |  |
    21     |  +--- submitted ---------+          |  |k
    22     |        |                 |          |  |
    23     |        |d                |e         |  |
    24     |        |        g        |          |  |
    25     +----- admitted ----- not admitted ---+  |
    26              |                               |
    27              |f                              |
    28              |                               |
    29            created --------------------------+
     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
    3030
    3131
    3232   a: start          -a: n/a
    33    b: pay, approve   -b: reset6
    34    c: submit         -c: reset5
     33   b: pay, approve   -b: reset1
     34   c: submit         -c: reset2
    3535   d: admit          -d: n/a
    3636   e: refuse1        -e: n/a
    37    f: create         -f: reset7
     37   f: create         -f: n/a
    3838   g: refuse2        -g: n/a
    39    h: n/a            -h: reset1
    40    i: n/a            -i: reset2
    41    j: n/a            -j: reset3
    42    k: n/a            -k: reset4
     39   h: n/a            -h: reset3
     40   i: n/a            -i: reset4
     41   j: n/a            -j: reset5
    4342
    44 
     43Application starts with the creation of the applicant record, either
     44by 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
     47passport picture and create a payment ticket. In contrast to student
     48payments, making a payment and redeeming a payment is done in one
     49step. Not only the ticket is marked ``paid``, but also the applicant
     50is automatically set to state ``paid`` **(b)**. After successful
     51payment the student can directly submit the application request
     52**(c)**. Submitted records can be either sent back for editing and
     53resubmission **(-c)**, accepted with admission confirmed **(d)** or
     54accepted with admission refused **(e)**. Only application records
     55with confirmed admission into the university can be transormed into
     56student records. This final and **irreversible step** is accompanied
     57by a transition to state ``created`` **(f)**.
    4558
    4659
Note: See TracChangeset for help on using the changeset viewer.