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

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

Officers must be aware of what they are doing when puring containers.

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