Changeset 13088 for main/waeup.kofa/trunk/docs
- Timestamp:
- 21 Jun 2015, 15:11:15 (10 years ago)
- 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 62 62 be moved from one container to another.** 63 63 64 The application mode is either ``create`` or ``update``. In create 65 mode, no record exists, the applicants container is empty. The records 66 are being created after submission of the first form. Applicants are 67 requested to provide all data needed, including their name details. 68 In update mode, the applicants container must have been prefilled by 69 import, e.g. with records provided by an external board. Applicants 70 can't create new records, they can only open and take possession of 71 existing records. Both methods have pros and cons. This is further 72 discussed below. 73 64 74 The application category is supplied by the 65 75 `ApplicationCategorySource` (see `application categories of base -
main/waeup.kofa/trunk/docs/source/userdocs/applicants/workflow.rst
r13083 r13088 11 11 |a 12 12 | 13 +--+--- started ----------------------+ --+14 | | | | |15 | | |b | |16 | | | | |17 | |h paid | |18 | | | j||19 i| | |c | |20 | | | | |21 | +--- submitted ---------+ | |k22 | | | | |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 30 30 31 31 32 32 a: start -a: n/a 33 b: pay, approve -b: reset 634 c: submit -c: reset 533 b: pay, approve -b: reset1 34 c: submit -c: reset2 35 35 d: admit -d: n/a 36 36 e: refuse1 -e: n/a 37 f: create -f: reset737 f: create -f: n/a 38 38 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 43 42 44 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)**. 45 58 46 59
Note: See TracChangeset for help on using the changeset viewer.