- Timestamp:
- 29 Apr 2015, 09:37:13 (10 years ago)
- Location:
- main/waeup.kofa/trunk
- Files:
-
- 3 edited
Legend:
- Unmodified
- Added
- Removed
-
main/waeup.kofa/trunk/docs/source/userdocs/datacenter/import_stages.rst
r12889 r12892 114 114 The data import is finalized by calling 115 115 :py:meth:`distProcessedFiles<waeup.kofa.datacenter.DataCenter.distProcessedFiles>`. 116 This method moves the ``.pending`` and ``.finished`` files from117 their temporary to their final location in the storage path ofthe118 filesystem from where they can be accessed through the browser user 119 interface.116 This method moves the ``.pending`` and ``.finished`` files as well as the 117 originally imported file from their temporary to their final location in the 118 storage path of the filesystem from where they can be accessed through the 119 browser user interface. -
main/waeup.kofa/trunk/docs/source/userdocs/datacenter/logging.rst
r12890 r12892 4 4 ******** 5 5 6 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.6 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. 7 7 8 8 .. note:: … … 59 59 ============== 60 60 61 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:: 62 63 2015-04-29 06:52:23,483 - INFO - admin - browser.pages.DatacenterUploadPage - uploaded: /kofa/trunk/var/datacenter/users_admin.csv 64 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) 65 2015-04-29 06:53:10,404 - INFO - admin - browser.pages.DatacenterPage - deleted: users_admin.update.pending.csv 66 2015-04-29 06:54:41,963 - INFO - admin - browser.pages.DatacenterUploadPage - uploaded: /kofa/trunk/var/datacenter/users2_admin.csv 67 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) 68 69 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. 70 71 Also the export of data (export, download and discard) is recorded in detail:: 72 73 2015-04-29 06:55:20,485 - INFO - admin - browser.pages.ExportCSVPage - exported: certificates, job_id=3036 74 2015-04-29 06:55:25,697 - INFO - admin - browser.pages.ExportCSVView - downloaded: WAeUP.Kofa_certificates_3036.csv, job_id=3036 75 2015-04-29 06:55:30,579 - INFO - admin - browser.pages.ExportCSVPage - discarded: job_id=3036 76 61 77 62 78 accesscodes.log 63 79 =============== 64 80 81 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:: 82 83 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) 84 2015-04-29 08:13:07,024 - INFO - admin - accesscodes.browser.BatchContainerSearchPage - disabled: ABC-1-6003657048 85 2015-04-29 08:13:11,502 - INFO - admin - accesscodes.browser.BatchContainerSearchPage - (re-)enabled: ABC-1-6003657048 86 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) 87 2015-04-29 08:14:14,152 - INFO - admin - accesscodes.browser.BatchContainerPage - deleted: ABC-1 88 89 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`. 90 65 91 66 92 applicants.log 67 93 ============== 94 95 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:: 96 97 2015-04-29 10:14:40,565 - INFO - admin - applicants.browser.ApplicantsContainerAddFormPage - added: app2015 98 2015-04-29 10:14:45,398 - INFO - admin - applicants.browser.ApplicantsContainerManageFormPage - app2015 - saved: startdate + enddate + application_fee 99 2015-04-29 10:15:08,779 - INFO - admin - app2015_262037 - Application initialized 100 2015-04-29 10:15:28,703 - INFO - admin - app2015_262037 - Application started 101 2015-04-29 10:15:28,704 - INFO - admin - applicants.browser.ApplicantManageFormPage - app2015_262037 - saved: reg_number + sex + course1 + date_of_birth 102 2015-04-29 10:16:38,921 - INFO - admin - app2015_262037 - Payment approved 103 2015-04-29 10:16:38,922 - INFO - admin - applicants.browser.OnlinePaymentApprovePage - app2015_262037 - payment approved: p4302953958139 104 2015-04-29 10:16:58,026 - INFO - admin - app2015_262037 - Application submitted 105 2015-04-29 10:17:01,040 - INFO - admin - applicants.browser.ApplicantManageFormPage - app2015_262037 - saved: course_admitted 106 2015-04-29 10:17:10,978 - INFO - admin - app2015_262037 - Applicant admitted 107 2015-04-29 10:17:10,979 - INFO - admin - applicants.browser.ApplicantManageFormPage - app2015_262037 - saved: locked 108 2015-04-29 10:17:34,135 - INFO - admin - app2015_262037 - Student record created (K1000004) 109 2015-04-29 10:45:15,298 - INFO - admin - app2015_262037 - Applicant record removed 110 2015-04-29 10:45:15,299 - INFO - admin - applicants.browser.ApplicantsRootManageFormPage - removed: app2015 111 112 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. 68 113 69 114 -
main/waeup.kofa/trunk/src/waeup/kofa/applicants/browser.py
r12664 r12892 172 172 self.flash(_('Successfully removed: ${a}', 173 173 mapping = {'a':', '.join(deleted)})) 174 ob_class = self.__implemented__.__name__.replace('waeup.kofa.','') 175 self.context.logger.info( 176 '%s - removed: %s' % (ob_class, ', '.join(deleted))) 174 177 self.redirect(self.url(self.context, '@@manage')+'#tab2') 175 178 return … … 228 231 self.context[code] = container 229 232 self.flash(_('Added:') + ' "%s".' % code) 233 ob_class = self.__implemented__.__name__.replace('waeup.kofa.','') 234 self.context.logger.info('%s - added: %s' % (ob_class, code)) 230 235 self.redirect(self.url(self.context, u'@@manage')) 231 236 return … … 381 386 self.flash(_('Form has been saved.')) 382 387 fields_string = ' + '.join(changed_fields) 383 self.context.writeLogMessage(self, 'saved: % 388 self.context.writeLogMessage(self, 'saved: %s' % fields_string) 384 389 return 385 390 … … 903 908 self.flash(_('Form has been saved.')) 904 909 if fields_string: 905 self.context.writeLogMessage(self, 'saved: % 910 self.context.writeLogMessage(self, 'saved: %s' % fields_string) 906 911 return 907 912
Note: See TracChangeset for help on using the changeset viewer.