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

.. _applicant_registration:

Registration
============

The `ApplicantRegistrationPage` allows to register in create or in
update mode, depending on the
:ref:`mode of its context<application_mode>`, i.e. the applicants
container.

In create mode, `firstname`, `middlename`, `lastname`, `email` and
`phone` are requested. A new record is being created.

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 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.


.. _form_locking:

Form Locking
============

We already mentioned regular :ref:`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.


.. _applicant_payment_tickets:

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.


.. _creating_students:

Creating Student Records
========================

As brought up in the :ref:`application_workflow` chapter, the final
step of the application process is the creation of the student
record on the basis of the application data. Only applicants in
state ``admitted`` can be turned into students. This is possible at
various application section levels:

1. Officers can create student records from single applicant
   records. A link button appears on the display page of each admitted
   applicants which directly triggers the creation process:

  |create_student_button|

2. The `ApplicantsContainerManageFormPage` provides a form button
   which allows to create student records from above selected
   applicants:

  |create_selected_students_button|

  Only admitted applicants will be processed. Other selected
  applicants will be skipped without further notice

3. Last but not least, the portal manager with user id ``admin``
   does see a link buttons:

  |create_students_button|

  on the `ApplicantsContainerPage` and on the `ApplicantsRootPage`
  which creates student records from applicants inside a single
  applicants container or even portal-wide respectively.

  The reader may wonder: Why only user ``admin``?

  Batch creation of thousands or even tenthousands of student records
  is very computation intensive and takes quite a long time, even on
  powerful computers. Experience has shown that the portal must be
  disconnected from the Internet in order to avoid database write
  conflict errors, which cannot be resolved if also students access
  the portal. Usually conflict errrors are not serious. Unresolved
  conflicts just lead to an error message and the database remains
  unchanged. Unfortunataly, student creation does not only affect the
  object database. As we will see below, also folders and files in the
  filesystem are added. These filesystem changes are not being
  reverted after unresolved conflicts. This may cause serious problems.

  So the answer to the question is trivial: We expect that the admin
  user knows what s/he is doing and is careful enough to start the
  creation process in maintenance mode, which means when the portal is
  set offline.



.. |create_student_button| image:: create_student_button.png
   :scale: 50 %

.. |create_students_button| image:: create_students_button.png
   :scale: 50 %

.. |create_selected_students_button| image:: create_selected_students_button.png
   :scale: 50 %