1 | .. _applicant_registration: |
---|
2 | |
---|
3 | Registration |
---|
4 | ============ |
---|
5 | |
---|
6 | The `ApplicantRegistrationPage` allows to register in create or in |
---|
7 | update mode, depending on the |
---|
8 | :ref:`mode of its context<application_mode>`, i.e. the applicants |
---|
9 | container. |
---|
10 | |
---|
11 | In create mode, `firstname`, `middlename`, `lastname`, `email` and |
---|
12 | `phone` are requested. An unused record is taken, or a new |
---|
13 | record is being created if no unused record is found (see |
---|
14 | :ref:`description of application modes <application_mode>`). |
---|
15 | |
---|
16 | In update mode, only `reg_number`, `lastname` and `email` have to be |
---|
17 | entered. Kofa searches for an applicant record with matching |
---|
18 | registration number and lowercased lastname. If the search does not |
---|
19 | yield a result, the flash message: 'No application record found' is |
---|
20 | returned. The anonymous user will not know, if the registration |
---|
21 | number does not exist or the provided lastname does not match. |
---|
22 | Another ``if`` statement checks whether the password has already |
---|
23 | been set and used, i.e. the application has already been |
---|
24 | started. If so, the anonymous user can't register again and is being |
---|
25 | requested to proceed to the login page. |
---|
26 | |
---|
27 | In both registration modes a randomly generated password is set and |
---|
28 | the email address is saved. An email with login credentials is sent |
---|
29 | to this address. Finally, the browser is redirected to a landing |
---|
30 | page. Depending on the portals configuration, the landing page tells |
---|
31 | the user that an email has been send to her/his mailbox, or even |
---|
32 | discloses additionally the login credentials. The disclosure of |
---|
33 | credentials has two substantial drawbacks: (1) The login credentials |
---|
34 | can be misused by web crawlers for bulk account creation, which may |
---|
35 | cause the system to crash. (2) The email address provided by the |
---|
36 | user is not being verified and there is no guarantee that the |
---|
37 | address belongs to the user or that a mailbox with such an address |
---|
38 | exists. Therefore, we strongly recommend to only send credentials to |
---|
39 | email addresses. |
---|
40 | |
---|
41 | |
---|
42 | .. _container_maintenance: |
---|
43 | |
---|
44 | Preparation and Maintenance of Applicants Containers |
---|
45 | ==================================================== |
---|
46 | |
---|
47 | As described in the :ref:`interfaces chapter <application_mode>`, |
---|
48 | applicants containers are aware of their application mode. In update |
---|
49 | mode, containers must be pre-filled by import with application |
---|
50 | records from an external board. In create mode, the container can |
---|
51 | remain empty. Each time an applicant registers, a new record is |
---|
52 | being created and a corresponding user account set up. This is the |
---|
53 | method of choice, if the number of expected applicants is not very |
---|
54 | high (e.g. less than 500). Since each single account creation causes |
---|
55 | a significant growth of Kofa's database, we strongly recommend to |
---|
56 | pre-fill applicants containers with empty application records, if |
---|
57 | the number of expected applicants is higher. Pre-filling is done in |
---|
58 | a single transaction and does thus save database volume when |
---|
59 | application is ongoing. |
---|
60 | |
---|
61 | During application, many records are being initialized but not used. |
---|
62 | For various reasons, many applicants do create one or more |
---|
63 | application records with corresponding user accounts but fail to log |
---|
64 | in. These records remain in state ``initialized`` and are never |
---|
65 | turned to state ``started``. After a while, these records can be |
---|
66 | safely removed. When purging an applicants container, also all |
---|
67 | unused pre-filled application records are being removed. If |
---|
68 | necessary, the container must be pre-filled with empty records again. |
---|
69 | |
---|
70 | |
---|
71 | .. _application_form_locking: |
---|
72 | |
---|
73 | Form Locking |
---|
74 | ============ |
---|
75 | |
---|
76 | We mentioned regular :ref:`page_locking` mechanisms. The |
---|
77 | `ApplicantEditFormPage` has two additional locks. One is the same |
---|
78 | named applicant attribute `locked`. Applicants can only enter the |
---|
79 | edit page if their record is 'unlocked'. Locking and unlocking is |
---|
80 | automatically done by workflow event handlers. By default, the |
---|
81 | record is unlocked. Only when the applicant submits the record, it |
---|
82 | is being locked, which means the attribute is set ``True`` and the |
---|
83 | data can no longer be edited. |
---|
84 | |
---|
85 | The reader may wonder why Kofa is not using the workflow state |
---|
86 | instead. The additional locking mechanism allows officers to unlock |
---|
87 | and lock forms without triggering workflow transitions. A transition |
---|
88 | is always a major, and sometimes inappropriate intervention which is |
---|
89 | also recorded in the application history. |
---|
90 | |
---|
91 | Use case: An applicant has made a mistake and requests a change of |
---|
92 | submitted data. An officer accepts the change, temporarily unlocks |
---|
93 | the form to allow editing the data. Unlocking and re-locking is |
---|
94 | logged in ``applicants.log`` but not shown on pages or the |
---|
95 | application slip. |
---|
96 | |
---|
97 | The second lock is induced by the application deadline. If the |
---|
98 | application period has expired and the applicants container's |
---|
99 | `strict_deadline` attribute is set, the applicant is also not |
---|
100 | allowed to edit or even submit the form. |
---|
101 | |
---|
102 | .. note:: |
---|
103 | |
---|
104 | A locked-out applicant can still login and access the display pages |
---|
105 | of the recod and also download payment and application slips. To |
---|
106 | expell an applicant from the portal, the account has to be suspended |
---|
107 | by setting the same-named attribute. |
---|
108 | |
---|
109 | |
---|
110 | .. _applicant_payment_tickets: |
---|
111 | |
---|
112 | Payment |
---|
113 | ======= |
---|
114 | |
---|
115 | In contrast to the students section, there is no |
---|
116 | `PaymentsManageFormPage` to handle payment tickets separately. |
---|
117 | Payment tickets can be viewed, added and removed directly on the |
---|
118 | applicant manage and edit form pages. Officers can remove all |
---|
119 | payment tickets, applicants only those without a response code |
---|
120 | (`r_code`) and, if the form is unlocked, so that they are allowed to |
---|
121 | edit their data. |
---|
122 | |
---|
123 | As already mentioned in the workflow chapter, making a payment and |
---|
124 | redeeming a payment is done in one step. When the payment was |
---|
125 | successful or has been approved, also the applicant is automatically |
---|
126 | set to state ``paid``. There is no need to redeem the ticket |
---|
127 | manually. |
---|
128 | |
---|