Changeset 13100 for main/waeup.kofa/trunk/docs/source/userdocs/applicants/browser.rst

Timestamp:

25 Jun 2015, 12:41:57 (9 years ago)

Author:

Henrik Bettermann

Message:

More docs.

File:

• main/waeup.kofa/trunk/docs/source/userdocs/applicants/browser.rst (modified) (4 diffs)

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

@@ -4 +4 @@
 ============
 
-The `ApplicantRegistrationPage` allows two register in create or in
+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
@@ -17 +17 @@
 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. A
-third ``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 is being requested to proceed to the login
-page.
+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
@@ -38 +38 @@
 
 
+.. _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:
 
@@ -43 +82 @@
 =======
 
+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.