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

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

Describe application workflow.

File size: 5.2 KB
Line 
1.. _applicants_interfaces:
2
3Parent Containers
4=================
5
6`IApplicantsRoot`
7-----------------
8
9Much like ``academics`` and ``students``, also ``applicants`` is a
10unique container (of type `ApplicantsRoot`) located in the
11`IUniversity` instance. It is the counterpart of the students
12(section) container. The root container has a `description` schema
13field attribute which contains human readable, multi-lingual
14information about the application procedure in HTML format. This
15description can be seen by anonymous users, when they enter the
16applicants section (by pressing the 'Application' tab in the
17navigation bar).
18
19.. _multilingual:
20
21.. note::
22
23  A multi-lingual or localized text is a sequence of human-readable
24  text strings in different languages. The languages must be separated
25  by ``>>xy<<``, whereas ``xy`` is the language code. Text parts
26  without correct leading language separator - usually the first part
27  has no language descriptor - are interpreted as texts in the
28  portal's language. The text strings can be either HTML or
29  reStructuredText (REST) formatted.
30
31.. literalinclude:: ../../../../src/waeup/kofa/applicants/interfaces.py
32   :pyobject: IApplicantsRoot
33
34`IApplicantsContainer`
35----------------------
36
37The applicants root contains the various `ApplicantsContainer`
38objects.
39
40.. literalinclude:: ../../../../src/waeup/kofa/applicants/interfaces.py
41   :pyobject: IApplicantsContainer
42
43`statistics` and `expired` are read-only property attributes.
44`description_dict` contains the same information as the
45`description`, but the sequence of language translations has been
46split up and copied into a dictionary for faster processing. In the
47base package, `local_roles` is an empty list which means, no local
48role can be assigned at applicants container level.
49
50Crucial for application are the `prefix`, `year`, `mode` and
51`application_category` schema fields. The `prefix` atribute can only
52be set when adding a container. It cannot be edited afterwards. The
53attribute determines the application type and automatically sets the
54prefix of the container code and of all applicant ids inside the
55container. The prefix is supplied by the `ApplicationTypeSource`
56(see `application types of base package
57<https://kofa-demo.waeup.org/sources#collapseAppTypes>`_). It is
58followed by the year of entry. Thus, the identifiers of applicants
59containers and the applicants inside the containers start with the
60same prefix-year sequence. Example: ``app2015`` which translates
61into 'General Studies 2015/2016'. Consequently, **applicants cannot
62be moved from one container to another.**
63
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
74The application category is supplied by the
75`ApplicationCategorySource` (see `application categories of base
76package <https://kofa-demo.waeup.org/sources#collapseAppCats>`_) and
77refers to a group of study programmes (certificates) which the
78applicant can apply for, read also chapter on :ref:`Certificates
79<certificate>`.
80
81Applicant
82=========
83
84As already mentioned, the applicant objects contains all information
85necessary for application, except for the payment ticket data. The
86base set of the applicant's 'external behaviour' is described by the
87following interface.
88
89`IApplicantBaseData`
90--------------------
91
92.. literalinclude:: ../../../../src/waeup/kofa/applicants/interfaces.py
93   :pyobject: IApplicantBaseData
94
95As usual, the interface lists attributes first. Except for the
96last two attributes (`password` and `application_date`), they are all
97read-only property attributes, i.e. attributes with a getter method
98only. These properties are computed dynamically and can't be set.
99
100In the base package `IApplicant` is derived from `IApplicantBaseData`
101and only two methods are added:
102
103`IApplicant`
104------------
105
106.. literalinclude:: ../../../../src/waeup/kofa/applicants/interfaces.py
107   :pyobject: IApplicant
108
109In custom packages we have furthermore interfaces for undergraduate
110and postgraduate students, both derived from `IApplicantBaseData`.
111
112Then there is a customized interface `ISpecialApplicant` for former
113students or students who are not users of the portal but have to pay
114supplementary fees. This reduced interface is used in browser
115components only, it does not instantiate applicant objects.
116
117Applicant Payment
118=================
119
120`IApplicantOnlinePayment`
121-------------------------
122
123Instances of this interface are called applicant payment tickets.
124They contain the data which confirm that the applicant has paid the
125application fee.
126`waeup.kofa.students.interfaces.IStudentOnlinePayment` inherits from
127`waeup.kofa.payments.interfaces.IOnlinePayment` and promises three
128additional methods which process the applicant data after successful
129or approved payment.
130
131.. literalinclude:: ../../../../src/waeup/kofa/applicants/interfaces.py
132   :pyobject: IApplicantOnlinePayment
Note: See TracBrowser for help on using the repository browser.