Changeset 12892 for main/waeup.kofa/trunk/docs

Timestamp:

29 Apr 2015, 09:37:13 (10 years ago)

Author:

Henrik Bettermann

Message:

More docs.

Location:

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

Files:

• import_stages.rst (modified) (1 diff)
• logging.rst (modified) (2 diffs)

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

@@ -114 +114 @@
 The data import is finalized by calling
 :py:meth:`distProcessedFiles<waeup.kofa.datacenter.DataCenter.distProcessedFiles>`.
-This method moves the ``.pending`` and ``.finished`` files from
-their temporary to their final location in the storage path of the
-filesystem from where they can be accessed through the browser user
-interface.
+This method moves the ``.pending`` and ``.finished`` files as well as the
+originally imported file from their temporary to their final location in the
+storage path of the filesystem from where they can be accessed through the
+browser user interface.

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

@@ -4 +4 @@
 ********
 
-Kofa is logging actions, which cause changes to the database or the filesystem, in separate human-redable event logfiles. Nearly all actions are being logged except those committed by applicants and students during registration periods. During these data initialization periods, applicants and students are requested to edit many fields and upload heaps of scanned documents. Logging all these changes would mean filling the logfiles with more or less useless or redundant information. The main purpose of Kofa's logging facilities is to trace changes effected by portal officers. Applicants and students can only access their own data. They don't have the permission to change anything else. Whereas portal officers bear responsibility for the integrity of the whole database. Depending on the roles they have, officers can add, edit or remove application and study data without leaving a trace in the object database itself. Kofa closes this security gap by recording nearly all actions of portal officers into various event logfiles.
+Kofa is logging actions, which cause changes to the database or the filesystem, in separate human-redable event logfiles. Nearly all actions are being logged, except those committed by applicants and students during registration periods. During these data initialization periods, applicants and students are requested to edit many fields and upload heaps of scanned documents. Logging all these changes would mean filling the logfiles with more or less useless or redundant information. The main purpose of Kofa's logging facilities is to trace changes effected by portal officers. Applicants and students can only access their own data. They don't have the permission to change anything else. Whereas portal officers bear responsibility for the integrity of the whole database. Depending on the roles they have, officers can add, edit or remove application and study data without leaving a trace in the object database itself. Kofa closes this security gap by recording nearly all actions of portal officers into various event logfiles.
 
 .. note::
@@ -59 +59 @@
 ==============
 
+All actions in the data center are logged in ``datacenter.log``. These are uploading import files, processing import files and downloading any kind of datacenter file::
+
+  2015-04-29 06:52:23,483 - INFO - admin - browser.pages.DatacenterUploadPage - uploaded: /kofa/trunk/var/datacenter/users_admin.csv
+  2015-04-29 06:52:44,025 - INFO - admin - processed: /kofa/trunk/var/datacenter/users_admin.csv, update mode, 3 lines (0 successful/ 3 failed), 0.129 s (0.0430 s/item)
+  2015-04-29 06:53:10,404 - INFO - admin - browser.pages.DatacenterPage - deleted: users_admin.update.pending.csv
+  2015-04-29 06:54:41,963 - INFO - admin - browser.pages.DatacenterUploadPage - uploaded: /kofa/trunk/var/datacenter/users2_admin.csv
+  2015-04-29 06:54:51,748 - INFO - admin - processed: /kofa/trunk/var/datacenter/users2_admin.csv, create mode, 3 lines (3 successful/ 0 failed), 0.024 s (0.0079 s/item)
+
+In the example above a user data file ``users.csv`` was uploaded and processed in update mode. The import failed since the 3 users didn't exist. The file was then deleted. User ``admin`` uploaded the file a second time. The file name had to be changed because the uploader does not allow to upload files with same name twice. The file was finally successfully processed in create mode.
+
+Also the export of data (export, download and discard) is recorded in detail::
+
+  2015-04-29 06:55:20,485 - INFO - admin - browser.pages.ExportCSVPage - exported: certificates, job_id=3036
+  2015-04-29 06:55:25,697 - INFO - admin - browser.pages.ExportCSVView - downloaded: WAeUP.Kofa_certificates_3036.csv, job_id=3036
+  2015-04-29 06:55:30,579 - INFO - admin - browser.pages.ExportCSVPage - discarded: job_id=3036
+
 
 accesscodes.log
 ===============
 
+The creation of access code batches, disabling and re-enabling of single access codes and archiving and removal of entire batches is logged as follows::
+
+  2015-04-29 08:12:26,091 - INFO - admin - accesscodes.browser.AddBatchPage - created: ABC-1-2015_04_29_06_12_24-admin.csv (1000, 2300.000000)
+  2015-04-29 08:13:07,024 - INFO - admin - accesscodes.browser.BatchContainerSearchPage - disabled: ABC-1-6003657048
+  2015-04-29 08:13:11,502 - INFO - admin - accesscodes.browser.BatchContainerSearchPage - (re-)enabled: ABC-1-6003657048
+  2015-04-29 08:14:13,668 - INFO - admin - accesscodes.browser.BatchContainerPage - archived: ABC-1 (ABC-1_archive-2015_04_29_06_14_13-admin.csv)
+  2015-04-29 08:14:14,152 - INFO - admin - accesscodes.browser.BatchContainerPage - deleted: ABC-1
+
+Not all access code workflow transitions are being logged. Each access code has a history attribute which contains a detailed list of all transitions. The history is shown on the `BatchContainerSearchPage`.
+
 
 applicants.log
 ==============
+
+The creation, editing and removal of applicants containers as well as editing application records (applicants) is being logged. Also the approval of payment tickets and all other payment ticket transactions are being recorded in ``applicants.log``. Kofa also logs all workflow transitions into both the applicant's history attribute and the logfile. Okay, this is somehow redundant, but it has proved useful to get a complete overview over all application data transactions also in the logfile. In return, Kofa does not aditionally log actions of browser pages if a workflow transition is triggered at the same time. Let's see the example::
+
+  2015-04-29 10:14:40,565 - INFO - admin - applicants.browser.ApplicantsContainerAddFormPage - added: app2015
+  2015-04-29 10:14:45,398 - INFO - admin - applicants.browser.ApplicantsContainerManageFormPage - app2015 - saved: startdate + enddate + application_fee
+  2015-04-29 10:15:08,779 - INFO - admin - app2015_262037 - Application initialized
+  2015-04-29 10:15:28,703 - INFO - admin - app2015_262037 - Application started
+  2015-04-29 10:15:28,704 - INFO - admin - applicants.browser.ApplicantManageFormPage - app2015_262037 - saved: reg_number + sex + course1 + date_of_birth
+  2015-04-29 10:16:38,921 - INFO - admin - app2015_262037 - Payment approved
+  2015-04-29 10:16:38,922 - INFO - admin - applicants.browser.OnlinePaymentApprovePage - app2015_262037 - payment approved: p4302953958139
+  2015-04-29 10:16:58,026 - INFO - admin - app2015_262037 - Application submitted
+  2015-04-29 10:17:01,040 - INFO - admin - applicants.browser.ApplicantManageFormPage - app2015_262037 - saved: course_admitted
+  2015-04-29 10:17:10,978 - INFO - admin - app2015_262037 - Applicant admitted
+  2015-04-29 10:17:10,979 - INFO - admin - applicants.browser.ApplicantManageFormPage - app2015_262037 - saved: locked
+  2015-04-29 10:17:34,135 - INFO - admin - app2015_262037 - Student record created (K1000004)
+  2015-04-29 10:45:15,298 - INFO - admin - app2015_262037 - Applicant record removed
+  2015-04-29 10:45:15,299 - INFO - admin - applicants.browser.ApplicantsRootManageFormPage - removed: app2015
+
+An applicants container was added first. The `startdate`,  `enddate` and the `application_fee` attributes were edited and a new application record (applicant) was added some seconds later. The `ApplicantManageFormPage` was opened, `reg_number`, `sex`, `course1` and `date_of_birth` was edited and the ``start`` transition was selected. This was done in the same transaction. The time difference between both log entries is only 0.001s. Furthermore, a payment ticket was created and the payment approved. Then the applicant was set to ``sumitted``, a `course_admitted` was selected and the applicant subsequently admitted. The form was automatically locked (see time difference). A student container was created and filled with the data from the application record. Finally, the entire applicants container including its content was removed in the same transaction, see time diffence between the last two log entries.