Changeset 13104 for main/waeup.kofa/trunk

Timestamp:

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

Author:

Henrik Bettermann

Message:

More docs.

Location:

main/waeup.kofa/trunk

Files:

• docs/source/userdocs/applicants/browser.rst (modified) (4 diffs)
• docs/source/userdocs/applicants/interfaces.rst (modified) (1 diff)
• docs/source/userdocs/browsing.rst (modified) (1 diff)
• docs/source/userdocs/datacenter/export.rst (modified) (1 diff)
• src/waeup/kofa/applicants/interfaces.py (modified) (1 diff)
• src/waeup/kofa/students/browser_templates/clearanceeditpage.pt (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

main/waeup.kofa/trunk/docs/source/userdocs/browsing.rst

@@ -112 +112 @@
 permissions the user gained. But this is not sufficient. Applicants
 and students always have the permission to handle their data
-although they are not allowed to edit the data all the time. The
-access to forms has to be further restricted. This is always done in
+although they are not allowed to edit the data all the time.
+Access to forms has to be further restricted. This is always done in
 the `update` method of a page. If an applicant or student doesn't
 meet the additional conditions defined in this method, s/he is

main/waeup.kofa/trunk/docs/source/userdocs/datacenter/export.rst

@@ -27 +27 @@
   In the Kofa base package only very few columns are being exported. In
   some Kofa custom packages tons of data are being gathered from
-  applicants and students and the number of columns increase accordingly.
+  applicants and students and the number of columns increases
+  accordingly.
 
 The `title` attribute unveils the name of the exporter under which

main/waeup.kofa/trunk/src/waeup/kofa/applicants/interfaces.py

@@ -449 +449 @@
 
     def writeLogMessage(view, comment):
-        """Adds an INFO message to the log file
+        """Add an INFO message to the log file.
         """
 
     def createStudent():
-        """Create a student object from applicatnt data
-        and copy applicant object.
+        """Create a student object from applicant data and copy
+        passport image and application slip.
         """
 

main/waeup.kofa/trunk/src/waeup/kofa/students/browser_templates/clearanceeditpage.pt

@@ -22 +22 @@
         </tbody>
       </table>
-
+      <br />
       <div tal:condition="view/availableActions">
         <input tal:repeat="action view/actions"