| [13099] | 1 | .. _applicant_registration: |
|---|
| [13078] | 2 | |
|---|
| [13099] | 3 | Registration |
|---|
| 4 | ============ |
|---|
| 5 | |
|---|
| [13100] | 6 | The `ApplicantRegistrationPage` allows to register in create or in |
|---|
| [13099] | 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. A new record is being created. |
|---|
| 13 | |
|---|
| 14 | In update mode, only `reg_number`, `lastname` and `email` have to be |
|---|
| 15 | entered. Kofa searches for an applicant record with matching |
|---|
| 16 | registration number and lowercased lastname. If the search does not |
|---|
| 17 | yield a result, the flash message: 'No application record found' is |
|---|
| 18 | returned. The anonymous user will not know, if the registration |
|---|
| [13100] | 19 | number does not exist or the provided lastname does not match. |
|---|
| 20 | Another ``if`` statement checks whether the password has already |
|---|
| 21 | been set and used, i.e. the the application has already been |
|---|
| 22 | started. If so, the anonymous user can't register again and is being |
|---|
| 23 | requested to proceed to the login page. |
|---|
| [13099] | 24 | |
|---|
| 25 | In both registration modes a randomly generated password is set and |
|---|
| 26 | the email address is saved. An email with login credentials is sent |
|---|
| 27 | to this address. Finally, the browser is redirected to a landing |
|---|
| 28 | page. Depending on the portals configuration, the landing page tells |
|---|
| 29 | the user that an email has been send to her/his mailbox, or even |
|---|
| 30 | discloses additionally the login credentials. The disclosure of |
|---|
| 31 | credentials has two substantial drawbacks: (1) The login credentials |
|---|
| 32 | can be misused by web crawlers for bulk account creation, which may |
|---|
| 33 | cause the system to crash. (2) The email address provided by the |
|---|
| 34 | user is not being verified and there is no guarantee that the |
|---|
| 35 | address belongs to the user or that a mailbox with such an address |
|---|
| 36 | exists. Therefore, we strongly recommend to only send credentials to |
|---|
| 37 | email addresses. |
|---|
| 38 | |
|---|
| 39 | |
|---|
| [13104] | 40 | .. _application_form_locking: |
|---|
| [13100] | 41 | |
|---|
| 42 | Form Locking |
|---|
| 43 | ============ |
|---|
| 44 | |
|---|
| [13104] | 45 | We mentioned regular :ref:`page_locking` mechanisms. The |
|---|
| [13100] | 46 | `ApplicantEditFormPage` has two additional locks. One is the same |
|---|
| 47 | named applicant attribute `locked`. Applicants can only enter the |
|---|
| 48 | edit page if their record is 'unlocked'. Locking and unlocking is |
|---|
| 49 | automatically done by workflow event handlers. By default, the |
|---|
| 50 | record is unlocked. Only when the applicant submits the record, it |
|---|
| 51 | is being locked, which means the attribute is set ``True`` and the |
|---|
| 52 | data can no longer be edited. |
|---|
| 53 | |
|---|
| 54 | The reader may wonder why Kofa is not using the workflow state |
|---|
| 55 | instead. The additional locking mechanism allows officers to unlock |
|---|
| 56 | and lock forms without triggering workflow transitions. A transition |
|---|
| 57 | is always a major, and sometimes inappropriate intervention which is |
|---|
| 58 | also recorded in the application history. |
|---|
| 59 | |
|---|
| 60 | Use case: An applicant has made a mistake and requests a change of |
|---|
| 61 | submitted data. An officer accepts the change, temporarily unlocks |
|---|
| 62 | the form to allow editing the data. Unlocking and re-locking is |
|---|
| 63 | logged in ``applicants.log`` but not shown on pages or the |
|---|
| 64 | application slip. |
|---|
| 65 | |
|---|
| 66 | The second lock is induced by the application deadline. If the |
|---|
| 67 | application period has expired and the applicants container's |
|---|
| 68 | `strict_deadline` attribute is set, the applicant is also not |
|---|
| 69 | allowed to edit or even submit the form. |
|---|
| 70 | |
|---|
| 71 | .. note:: |
|---|
| 72 | |
|---|
| 73 | A locked-out applicant can still login and access the display pages |
|---|
| 74 | of the recod and also download payment and application slips. To |
|---|
| 75 | expell an applicant from the portal, the account has to be suspended |
|---|
| 76 | by setting the same-named attribute. |
|---|
| 77 | |
|---|
| 78 | |
|---|
| [13099] | 79 | .. _applicant_payment_tickets: |
|---|
| 80 | |
|---|
| 81 | Payment |
|---|
| 82 | ======= |
|---|
| 83 | |
|---|
| [13100] | 84 | In contrast to the students section, there is no |
|---|
| 85 | `PaymentsManageFormPage` to handle payment tickets separately. |
|---|
| 86 | Payment tickets can be viewed, added and removed directly on the |
|---|
| 87 | applicant manage and edit form pages. Officers can remove all |
|---|
| 88 | payment tickets, applicants only those without a response code |
|---|
| 89 | (`r_code`) and, if the form is unlocked, so that they are allowed to |
|---|
| 90 | edit their data. |
|---|
| [13099] | 91 | |
|---|
| [13100] | 92 | As already mentioned in the workflow chapter, making a payment and |
|---|
| 93 | redeeming a payment is done in one step. When the payment was |
|---|
| 94 | successful or has been approved, also the applicant is automatically |
|---|
| 95 | set to state ``paid``. There is no need to redeem the ticket |
|---|
| 96 | manually. |
|---|
| [13099] | 97 | |
|---|
