1 | .. _applicants_interfaces: |
---|
2 | |
---|
3 | Parent Containers Interfaces |
---|
4 | ============================ |
---|
5 | |
---|
6 | `IApplicantsRoot` |
---|
7 | ----------------- |
---|
8 | |
---|
9 | Much like ``academics`` and ``students``, also ``applicants`` is a |
---|
10 | unique 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 |
---|
13 | field attribute which contains human readable, multi-lingual |
---|
14 | information about the application procedure in HTML format. This |
---|
15 | description can be seen by anonymous users, when they enter the |
---|
16 | applicants section (by pressing the 'Application' tab in the |
---|
17 | navigation 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 | |
---|
37 | The applicants root contains the various `ApplicantsContainer` |
---|
38 | objects and is also a configuration object. |
---|
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 |
---|
46 | split up and copied into a dictionary for faster processing. |
---|
47 | |
---|
48 | Crucial for application are the `prefix`, `year`, `mode` and |
---|
49 | `application_category` schema fields. The `prefix` atribute can only |
---|
50 | be set when adding a container. It cannot be edited afterwards. The |
---|
51 | attribute determines the application type and automatically sets the |
---|
52 | prefix of the container code and of all applicant ids inside the |
---|
53 | container. The prefix is supplied by the `ApplicationTypeSource` |
---|
54 | (see `application types of base package |
---|
55 | <https://kofa-demo.waeup.org/sources#collapseAppTypes>`_). It is |
---|
56 | followed by the year of entry. Thus, the identifiers of applicants |
---|
57 | containers and the applicants inside the containers start with the |
---|
58 | same prefix-year sequence. Example: ``app2015`` which translates |
---|
59 | into 'General Studies 2015/2016'. Consequently, **applicants cannot |
---|
60 | be moved from one container to another.** |
---|
61 | |
---|
62 | .. _application_mode: |
---|
63 | |
---|
64 | The application mode is either ``create`` or ``update``. In **create |
---|
65 | mode** the container can be either left empty or it can be |
---|
66 | pre-filled with fresh and 'unused' records. In the first case, |
---|
67 | records are being created after submission of the first form. In the |
---|
68 | second case, unused record are fetched and filled with the form |
---|
69 | data. In both 'create mode' cases, applicants are requested to |
---|
70 | provide all data needed, including their name details. In **update |
---|
71 | mode**, the applicants container must have been pre-filled by import, |
---|
72 | e.g. with records provided by an external board. These records are |
---|
73 | called 'used' since they already contain data. Applicants can't |
---|
74 | create new records in update mode, they can only open and take |
---|
75 | possession of existing records. |
---|
76 | |
---|
77 | The application category is supplied by the |
---|
78 | `ApplicationCategorySource` (see `application categories of base |
---|
79 | package <https://kofa-demo.waeup.org/sources#collapseAppCats>`_) and |
---|
80 | refers to a group of study programmes (certificates) which the |
---|
81 | applicant can apply for, read also chapter on :ref:`Certificates |
---|
82 | <certificate>`. |
---|
83 | |
---|
84 | Applicant Interfaces |
---|
85 | ==================== |
---|
86 | |
---|
87 | As already mentioned, the applicant objects contains all information |
---|
88 | necessary for application, except for the payment ticket data. The |
---|
89 | base set of the applicant's 'external behaviour' is described by the |
---|
90 | following interface. |
---|
91 | |
---|
92 | `IApplicantBaseData` |
---|
93 | -------------------- |
---|
94 | |
---|
95 | .. literalinclude:: ../../../../src/waeup/kofa/applicants/interfaces.py |
---|
96 | :pyobject: IApplicantBaseData |
---|
97 | |
---|
98 | As usual, the interface lists attributes first. Except for the |
---|
99 | last two attributes (`password` and `application_date`), they are all |
---|
100 | read-only property attributes, i.e. attributes with a getter method |
---|
101 | only. These properties are computed dynamically and can't be set. |
---|
102 | |
---|
103 | `IApplicant` |
---|
104 | ------------ |
---|
105 | |
---|
106 | In the base package `IApplicant` is derived from `IApplicantBaseData` |
---|
107 | and only two methods are added: |
---|
108 | |
---|
109 | .. literalinclude:: ../../../../src/waeup/kofa/applicants/interfaces.py |
---|
110 | :pyobject: IApplicant |
---|
111 | |
---|
112 | In custom packages we have furthermore interfaces for undergraduate |
---|
113 | and postgraduate students, both derived from `IApplicantBaseData`. |
---|
114 | |
---|
115 | Then there is a customized interface `ISpecialApplicant` for former |
---|
116 | students or students who are not users of the portal but have to pay |
---|
117 | supplementary fees. This reduced interface is used in browser |
---|
118 | components only, it does not instantiate applicant objects. |
---|
119 | |
---|
120 | Applicant Payment Interfaces |
---|
121 | ============================ |
---|
122 | |
---|
123 | `IApplicantOnlinePayment` |
---|
124 | ------------------------- |
---|
125 | |
---|
126 | Instances of this interface are called applicant payment tickets. |
---|
127 | They contain the data which confirm that the applicant has paid the |
---|
128 | application fee. |
---|
129 | `waeup.kofa.students.interfaces.IStudentOnlinePayment` inherits from |
---|
130 | `waeup.kofa.payments.interfaces.IOnlinePayment` and promises three |
---|
131 | additional methods which process the applicant data after successful |
---|
132 | or approved payment. |
---|
133 | |
---|
134 | .. literalinclude:: ../../../../src/waeup/kofa/applicants/interfaces.py |
---|
135 | :pyobject: IApplicantOnlinePayment |
---|