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

Last change on this file since 17650 was 13273, checked in by Henrik Bettermann, 9 years ago

Fix some typos.

File size: 2.9 KB
RevLine 
[13076]1.. _applicants_section:
[12829]2
[13078]3Applicants Section
4******************
[13075]5
[13078]6Applicants and students are different entities and stored in
7different places. Moreover, the students section is completely
8independent from the applicants section. Kofa can be configured
9without its `applicants` module but not without its `students`
10module.
[13075]11
[13078]12Anonymous users can self-register and automatically become
13applicants (users) of the portal. The number of applicants is not
14limited and, theoretically, Kofa can host hundredthousands of
15applicants in various applicants containers. Usually, only a few of
16them are beeing accepted for studying at the university. Once the
17application process has ended, admitted applicants are transformed
18into student records. New student records are created and the data
19are copied from the applicant records. When this 'student creation'
20process is finished, the applicant records are dispensable. Aim was
21to provide an easy way to get rid of the huge batches of applicant
22records by only one click, in order to keep the database clean and
23tidy. The process is described further below.
[13075]24
25.. note::
26
[13078]27  The term 'application' has a double meaning in English. An
28  'application' in computer sciences stands for a software or web
29  application. Software developers may get confused by using the term
30  in a different context. To take this into account, we prefer to
31  speak of 'applicant' in this documentation, instead of 'application'
32  although, in the linguistic context, it sometimes makes more sense
33  to speak of the latter. However, in the user interface (UI) and also
34  in Python docstrings the term 'application' predominates.
[13076]35
[13273]36Much like students, applicants are also users of the portal and
[13078]37the applicant object is a user account surrogate, see
38:ref:`Applicants and Students <applicants_and_students>`. In the
39following we always refer to the applicant container when talking
40about an applicant.
41
[13273]42In contrast to student containers, applicant containers do not
[13078]43contain subcontainers. The only objects they contain are applicant
44payment tickets (i.e. instances of `ApplicantOnlinePayment`). Thus
45the hierarchy is flat and not really treelike as the students
46section. Also, applicants (applicant containers) are stored in
47different parent containers (instances of `IApplicantsContainer`).
48There is not one single parent container like in the students
49section but one container for each application session and
50application type::
51
52  Applicants Section (ApplicantsRoot)
53  |
54  +---> ApplicantsContainer
55        |
56        +---> Applicant
57              |
58              +-----> ApplicantOnlinePayment
59
60
61Interfaces
62==========
63
64.. toctree::
65   :maxdepth: 3
66
67   applicants/interfaces
68
69Workflow & History
70==================
71
72.. toctree::
73   :maxdepth: 3
74
75   applicants/workflow
76
77Browser Pages
78=============
79
80.. toctree::
81   :maxdepth: 3
82
83   applicants/browser
84
85
[13108]86Student Record Creation
87=======================
[13078]88
[13108]89.. toctree::
90   :maxdepth: 3
91
92   applicants/create_students
93
Note: See TracBrowser for help on using the repository browser.