Changeset 13104 for main/waeup.kofa/trunk/docs/source/userdocs/applicants

Timestamp:

26 Jun 2015, 09:04:51 (9 years ago)

Author:

Henrik Bettermann

Message:

More docs.

Location:

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

Files:

• browser.rst (modified) (4 diffs)
• interfaces.rst (modified) (1 diff)

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

@@ -38 +38 @@
 
 
-.. _form_locking:
+.. _application_form_locking:
 
 Form Locking
 ============
 
-We already mentioned regular :ref:`page_locking` mechanisms. The
+We 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
@@ -135 +135 @@
 
   Batch creation of thousands or even tenthousands of student records
-  is very computation intensive and takes quite a long time, even on
+  is very computation intensive and takes quite a long time, even with
   powerful computers. Experience has shown that the portal must be
   disconnected from the Internet in order to avoid database write
@@ -141 +141 @@
   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
+  unchanged. Unfortunataly, student creation does not only alter 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.
+  reverted after unresolved conflicts, a fact which can 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.
+  disconnected from a public network.
 
 
@@ -162 +163 @@
    :scale: 50 %
 
+`Applicant.createStudent`
+-------------------------
+
+The `createStudent` method is called for each admitted applicant.
+The method performs a series of checks before it creates a new
+student record:
+
+1. Is the applicant really in the correct state?
+
+2. Has the registration number not been assigned to another student?
+
+3. Is a certificate (`course_admitted`) provided?
+
+4. Can all required student attributes be copied and set? The
+   following attributes are copied:
+
+   .. autoattribute:: waeup.kofa.applicants.applicant.Applicant.applicant_student_mapping
+      :noindex:
+
+5. Can the application slip can be created? Defective images may
+   cause the adapter method to raise an exception (``IOError``).
+
+If all these checks are passed, a new student record is created, a
+password is set, the transitions ``create`` and ``admit`` are fired
+and all student study course attributes are set. These are the
+changes which affect the database.
+
+Furthermore, `createStudent` also produces an application slip pdf
+file, creates a new folder for the student in the filesystem and
+copies the pdf file together with the passport jpeg image file into
+the newly created folder. The copied application slip ensures, that
+the original application data do not get lost, when the application
+section is being purged.
+
+As mentioned above, folder creation and file copying are not being
+rolled back if the database transactions fails, e.g. due to write
+conflict errors. Therefore, batch student creation should only be
+performed if the portal is offline.

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

@@ -100 +100 @@
 only. These properties are computed dynamically and can't be set.
 
+`IApplicant`
+------------
+
 In the base package `IApplicant` is derived from `IApplicantBaseData`
 and only two methods are added:
-
-`IApplicant`
-------------
 
 .. literalinclude:: ../../../../src/waeup/kofa/applicants/interfaces.py