Registration

The ApplicantRegistrationPage allows to register in create or in update mode, depending on the mode of its context, i.e. the applicants container.

In create mode, firstname, middlename, lastname, email and phone are requested. An unused record is taken, or a new record is being created if no unused record is found (see description of application modes).

In update mode, only reg_number, lastname and email have to be entered. Kofa searches for an applicant record with matching registration number and lowercased lastname. If the search does not yield a result, the flash message: ‘No application record found’ is returned. The anonymous user will not know, if the registration number does not exist or the provided lastname does not match. Another if statement checks whether the password has already been set and used, i.e. the application has already been started. If so, the anonymous user can’t register again and is being requested to proceed to the login page.

In both registration modes a randomly generated password is set and the email address is saved. An email with login credentials is sent to this address. Finally, the browser is redirected to a landing page. Depending on the portals configuration, the landing page tells the user that an email has been send to her/his mailbox, or even discloses additionally the login credentials. The disclosure of credentials has two substantial drawbacks: (1) The login credentials can be misused by web crawlers for bulk account creation, which may cause the system to crash. (2) The email address provided by the user is not being verified and there is no guarantee that the address belongs to the user or that a mailbox with such an address exists. Therefore, we strongly recommend to only send credentials to email addresses.

Preparation and Maintenance of Applicants Containers

As described in the interfaces chapter, applicants containers are aware of their application mode. In update mode, containers must be pre-filled by import with application records from an external board. In create mode, the container can remain empty. Each time an applicant registers, a new record is being created and a corresponding user account set up. This is the method of choice, if the number of expected applicants is not very high (e.g. less than 500). Since each single account creation causes a significant growth of Kofa’s database, we strongly recommend to pre-fill applicants containers with empty application records, if the number of expected applicants is higher. Pre-filling is done in a single transaction and does thus save database volume when application is ongoing.

During application, many records are being initialized but not used. For various reasons, many applicants do create one or more application records with corresponding user accounts but fail to log in. These records remain in state initialized and are never turned to state started. After a while, these records can be safely removed. When purging an applicants container, also all unused pre-filled application records are being removed. If necessary, the container must be pre-filled with empty records again.

Form Locking

We mentioned regular Page Locking mechanisms. The ApplicantEditFormPage has two additional locks. One is the same named applicant attribute locked. Applicants can only enter the edit page if their record is ‘unlocked’. Locking and unlocking is automatically done by workflow event handlers. By default, the record is unlocked. Only when the applicant submits the record, it is being locked, which means the attribute is set True and the data can no longer be edited.

The reader may wonder why Kofa is not using the workflow state instead. The additional locking mechanism allows officers to unlock and lock forms without triggering workflow transitions. A transition is always a major, and sometimes inappropriate intervention which is also recorded in the application history.

Use case: An applicant has made a mistake and requests a change of submitted data. An officer accepts the change, temporarily unlocks the form to allow editing the data. Unlocking and re-locking is logged in applicants.log but not shown on pages or the application slip.

The second lock is induced by the application deadline. If the application period has expired and the applicants container’s strict_deadline attribute is set, the applicant is also not allowed to edit or even submit the form.

Note

A locked-out applicant can still login and access the display pages of the recod and also download payment and application slips. To expell an applicant from the portal, the account has to be suspended by setting the same-named attribute.

Payment

In contrast to the students section, there is no PaymentsManageFormPage to handle payment tickets separately. Payment tickets can be viewed, added and removed directly on the applicant manage and edit form pages. Officers can remove all payment tickets, applicants only those without a response code (r_code) and, if the form is unlocked, so that they are allowed to edit their data.

As already mentioned in the workflow chapter, making a payment and redeeming a payment is done in one step. When the payment was successful or has been approved, also the applicant is automatically set to state paid. There is no need to redeem the ticket manually.