Index: main/waeup.kofa/trunk/docs/source/userdocs/datacenter/export.rst
===================================================================
--- main/waeup.kofa/trunk/docs/source/userdocs/datacenter/export.rst	(revision 12869)
+++ main/waeup.kofa/trunk/docs/source/userdocs/datacenter/export.rst	(revision 12870)
@@ -4,13 +4,33 @@
 ***********
 
-Regular data exporters (1) collect objects from specific containers, (2) iterate over the collected objects, (3) extract and mangle information from each object, (4) write the information of each object into a row of a CSV file and (5) finally provide the file for download. The CSV file is neither stored in the database nor archived in the filesystem. (3) and (4) means a flattening of the hierarchical data structure, i.e. a mapping of objects to flat relational data to be stored in a CSV table. The extracted information must not necessarily be based only on static attributes of the collected object. The data, finally stored in the CSV file, can also be derived from parent or child objects, or dynamically computed by the object's methods and property attributes. These methods and properties can retrieve information from everywhere in the portal's database.
-
-In the following we list all exporter classes including two attributes and a method description. The `fields` attribute contain the column titles of the export file. These are not necessarily only attributes of the exported objects.
+Regular data exporters (1) collect objects from specific containers,
+(2) iterate over the collected objects, (3) extract and mangle
+information from each object, (4) write the information of each object
+into a row of a CSV file and (5) finally provide the file for
+download. The CSV file is neither stored in the database nor archived
+in the filesystem. (3) and (4) means a flattening of the hierarchical
+data structure, i.e. a mapping of objects to flat relational data to
+be stored in a CSV table. The extracted information must not
+necessarily be based only on static attributes of the collected
+object. The data, finally stored in the CSV file, can also be derived
+from parent or child objects, or dynamically computed by the object's
+methods and property attributes. These methods and properties can
+retrieve information from everywhere in the portal's database. In the
+following we list all exporter classes including two attributes and a
+method description. The `fields` attribute contain the column titles
+of the export file. These are not necessarily only attributes of the
+exported objects.
 
 .. note::
 
-  The list of exported columns usually underlies heavy customizations. 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.
-
-The `title` attribute unveils the name of the exporter under which this exporter will be displayed in the user interface. The `mangle_value()` method shows how some of fields are being dynamically computed.
+The list of exported columns usually underlies heavy customizations.
+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.
+
+The `title` attribute unveils the name of the exporter under which
+this exporter will be displayed in the user interface. The
+`mangle_value()` method shows how some of fields are being dynamically
+computed.
 
 Regular Exporters
@@ -139,7 +159,24 @@
 ======================
 
-When starting a Student Data Exporter in the Data Center all student records will be taken into consideration, no matter what or where a student is studying. The exporter can also be started 'locally' at various levels in the academic section. Starting one of the exporters e.g. at faculty or department level means that only the data of students are exported who study in this faculty or department respectively. The exporter can also be started at certificate level. Then only the data of students, who are studying the named study course, will be taken into account. At course level the data of those students are being exported who have attended or taken this specific course.
-
-Student Data Exporter can be further configured through a configuration page. Search parameters like the student's current level, current session and current study mode  can be set to filter sets of students in order to decrease the size of the export file. The set of filter parameters varies and depends on the 'locatation' from where the exporter is called. A completely different set of filter parameters is provided for courses. In this case the session and level can be selected when the course was taken by the student.
+When starting a Student Data Exporter in the Data Center all student
+records will be taken into consideration, no matter what or where a
+student is studying. The exporter can also be started 'locally' at
+various levels in the academic section. Starting one of the exporters
+e.g. at faculty or department level means that only the data of
+students are exported who study in this faculty or department
+respectively. The exporter can also be started at certificate level.
+Then only the data of students, who are studying the named study
+course, will be taken into account. At course level the data of those
+students are being exported who have attended or taken this specific
+course.
+
+Student Data Exporter can be further configured through a
+configuration page. Search parameters like the student's current level,
+ current session and current study mode can be set to filter sets of
+students in order to decrease the size of the export file. The set of
+filter parameters varies and depends on the 'locatation' from where
+the exporter is called. A completely different set of filter
+parameters is provided for courses. In this case the session and level
+can be selected when the course was taken by the student.
 
 Student Exporter
@@ -203,5 +240,11 @@
   .. automethod:: waeup.kofa.students.export.BedTicketExporter.mangle_value()
 
-The above exporters refer to a specific content type (object class). They export all attributes of these objects and a few additional parameters derived from the parent objects. These exporters can be used for reimport, or more precisely for backing up and restoring data. The following 'special' exporters are made on request of some universities to collect and compose student data for analysis and postprocessing by the university.
+The above exporters refer to a specific content type (object class).
+They export all attributes of these objects and a few additional
+parameters derived from the parent objects. These exporters can be
+used for reimport, or more precisely for backing up and restoring
+data. The following 'special' exporters are made on request of some
+universities to collect and compose student data for analysis and
+postprocessing by the university.
 
 DataForBursary Exporter
Index: main/waeup.kofa/trunk/docs/source/userdocs/datacenter/import.rst
===================================================================
--- main/waeup.kofa/trunk/docs/source/userdocs/datacenter/import.rst	(revision 12869)
+++ main/waeup.kofa/trunk/docs/source/userdocs/datacenter/import.rst	(revision 12870)
@@ -4,103 +4,8 @@
 ***********
 
-Stages of Batch Processing
-==========================
+.. toctree::
+   :maxdepth: 3
 
-The term 'data import' actually understates the range of functions importers really have. As already stated, many importers do not only restore data once backed up by exporters or, in other words, take values from CSV files and write them one-on-one into the database. The data undergo a complex staged data processing algorithm. Therefore, we prefer calling them 'batch processors' instead of importers. The stages of the import process are as follows.
+   import_stages
+   import_processors
 
-Stage 1: File Upload
---------------------
-
-Users with permission
-:py:class:`waeup.manageDataCenter<waeup.kofa.permissions.ManageDataCenter>`
-are allowed to access the data center and also to use the upload page. On this page they can see a long table of available batch processors. The table lists required, optional and non-schema fields (see below) for each processor. It also provides a CSV file template which can be filled and uploaded to avoid header errors.
-
-Data center managers can upload any kind of CSV file from their local computer. The uploader does not check the integrity of the content but the validity of its CSV encoding (see :py:func:`check_csv_charset<waeup.kofa.utils.helpers.check_csv_charset>`). It also checks the filename extension and allows only a limited number of files in the data center.
-
-.. autoattribute:: waeup.kofa.browser.pages.DatacenterUploadPage.max_files
-
-If the upload succeeded the uploader sends an email to all import managers (users with role :py:class:`waeup.ImportManager<waeup.kofa.permissions.ImportManager>`) of the portal that a new file was uploaded.
-
-The uploader changes the filename. An uploaded file ``foo.csv`` will be stored as ``foo_USERNAME.csv`` where username is the user id of the currently logged in user. Spaces in filename are replaced by underscores. Pending data filenames remain unchanged (see below).
-
-After file upload the data center manager can click the 'Process data' button to open the page where files can be selected for import (**import step 1**). After selecting a file the data center manager can preview the header and the first three records of the uploaded file (**import step 2**). If the preview fails or the header contains duplicate column titles, an error message is raised. The user cannot proceed but is requested to replace the uploaded file. If the preview succeeds the user is able to proceed to the next step (**import step 3**) by selecting the appropriate processor and an import mode. In import mode ``create`` new objects are added to the database, `in `update`` mode existing objects are modified and in ``remove`` mode deleted.
-
-Stage 2: File Header Validation
--------------------------------
-
-Import step 3 is the stage where the file content is assessed for the first time and checked if the column titles correspond with the fields of the processor chosen. The page shows the header and the first record of the uploaded file. The page allows to change column titles or to ignore entire columns during import. It might have happened that one or more column titles are misspelled or that the person, who created the file, ignored the case-sensitivity of field names. Then the data import manager can easily fix this by selecting the correct title and click the 'Set headerfields' button. Setting the column titles is temporary, it does not modify the uploaded file. Consequently, it does not make sense to set new column titles if the file is not imported afterwards.
-
-The page also calls the `checkHeaders` method of the batch processor which checks for required fields. If a required column title is missing, a warning message is raised and the user can't proceed to the next step (**import step 4**).
-
-Stage 3: Data Validation and Import
------------------------------------
-
-Import step 4 is the actual data import. The import is started by clicking the 'Perform import' button.
-
-Kofa does not validate the data in advance. It tries to import the data row-by-row while reading the CSV file. The reason is that import files very often  contain thousands or even tenthousands of records. It is not feasable for data managers to edit import files until they are error-free. Very often such an error is not really a mistake made by the person who compiled the file. Example: The import file contains course results although the student has not yet registered the courses. Then the import of this single record has to wait, i.e. it has to be marked pending, until the student has added the course ticket. Only then it can be edited by the batch processor.
-
-The core import method is:
-
-.. automethod:: waeup.kofa.utils.batching.BatchProcessor.doImport()
-   :noindex:
-
-Stage 4: Post-Processing
-------------------------
-
-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 browser user interface.
-
-Batch Processors
-================
-
-All batch processors inherit from the :py:class:`waeup.kofa.utils.batching.BatchProcessor` base class. The `doImport` method, described above, always remains unchanged. All processors have a property `available_fields` which defines the set of importable data. They correspond with the column titles of the import file. Available fields are usually composed of location fields, interface fields and additional fields. Overlaps are possible. Location fields define the minumum set of fields which are necessary to locate an existing object in order to update or remove it. Interface fields (schema fields) are the fields defined in the interface of the data entity. Additional fields are additionally needed for data processing. We further distinguish between required and optional fields or between schema and non-schema fields.
-
-In the following we list all available processors of the Kofa base package including some important methods which describe them best. We do not list available fields of each processor here. Available fields are shown in the browser user interface on the upload page of the portal.
-
-User Processor
---------------
-
-.. autoclass:: waeup.kofa.authentication.UserProcessor()
-  :noindex:
-
-Faculty Processor
------------------
-
-.. autoclass:: waeup.kofa.university.batching.FacultyProcessor()
-  :noindex:
-
-Department Processor
---------------------
-
-.. autoclass:: waeup.kofa.university.batching.DepartmentProcessor()
-  :noindex:
-
-Certificate Processor
----------------------
-
-.. autoclass:: waeup.kofa.university.batching.CertificateProcessor()
-  :noindex:
-
-Course Processor
-----------------
-
-.. autoclass:: waeup.kofa.university.batching.CourseProcessor()
-  :noindex:
-
-
-Certificate Course Processor
-----------------------------
-
-.. autoclass:: waeup.kofa.university.batching.CertificateCourseProcessor()
-  :noindex:
-
-Applicants Container Processor
-------------------------------
-
-.. autoclass:: waeup.kofa.applicants.batching.ApplicantsContainerProcessor()
-  :noindex:
-
-Applicant Processor
--------------------
-
-.. autoclass:: waeup.kofa.applicants.batching.ApplicantProcessor()
-  :noindex:
Index: main/waeup.kofa/trunk/docs/source/userdocs/datacenter/import_processors.rst
===================================================================
--- main/waeup.kofa/trunk/docs/source/userdocs/datacenter/import_processors.rst	(revision 12870)
+++ main/waeup.kofa/trunk/docs/source/userdocs/datacenter/import_processors.rst	(revision 12870)
@@ -0,0 +1,63 @@
+.. _import_processors:
+
+Batch Processors
+****************
+
+All batch processors inherit from the :py:class:`waeup.kofa.utils.batching.BatchProcessor` base class. The `doImport` method, described above, always remains unchanged. All processors have a property `available_fields` which defines the set of importable data. They correspond with the column titles of the import file. Available fields are usually composed of location fields, interface fields and additional fields. Overlaps are possible. Location fields define the minumum set of fields which are necessary to locate an existing object in order to update or remove it. Interface fields (schema fields) are the fields defined in the interface of the data entity. Additional fields are additionally needed for data processing. We further distinguish between required and optional fields or between schema and non-schema fields.
+
+In the following we list all available processors of the Kofa base package including some important methods which describe them best. We do not list available fields of each processor here. Available fields are shown in the browser user interface on the upload page of the portal.
+
+Regular Processors
+==================
+
+User Processor
+--------------
+
+.. autoclass:: waeup.kofa.authentication.UserProcessor()
+  :noindex:
+
+Faculty Processor
+-----------------
+
+.. autoclass:: waeup.kofa.university.batching.FacultyProcessor()
+  :noindex:
+
+Department Processor
+--------------------
+
+.. autoclass:: waeup.kofa.university.batching.DepartmentProcessor()
+  :noindex:
+
+Certificate Processor
+---------------------
+
+.. autoclass:: waeup.kofa.university.batching.CertificateProcessor()
+  :noindex:
+
+Course Processor
+----------------
+
+.. autoclass:: waeup.kofa.university.batching.CourseProcessor()
+  :noindex:
+
+
+Certificate Course Processor
+----------------------------
+
+.. autoclass:: waeup.kofa.university.batching.CertificateCourseProcessor()
+  :noindex:
+
+Application Data Processors
+===========================
+
+Applicants Container Processor
+------------------------------
+
+.. autoclass:: waeup.kofa.applicants.batching.ApplicantsContainerProcessor()
+  :noindex:
+
+Applicant Processor
+-------------------
+
+.. autoclass:: waeup.kofa.applicants.batching.ApplicantProcessor()
+  :noindex:
Index: main/waeup.kofa/trunk/docs/source/userdocs/datacenter/import_stages.rst
===================================================================
--- main/waeup.kofa/trunk/docs/source/userdocs/datacenter/import_stages.rst	(revision 12870)
+++ main/waeup.kofa/trunk/docs/source/userdocs/datacenter/import_stages.rst	(revision 12870)
@@ -0,0 +1,47 @@
+.. _import_stages:
+
+Stages of Batch Processing
+**************************
+
+The term 'data import' actually understates the range of functions importers really have. As already stated, many importers do not only restore data once backed up by exporters or, in other words, take values from CSV files and write them one-on-one into the database. The data undergo a complex staged data processing algorithm. Therefore, we prefer calling them 'batch processors' instead of importers. The stages of the import process are as follows.
+
+Stage 1: File Upload
+====================
+
+Users with permission
+:py:class:`waeup.manageDataCenter<waeup.kofa.permissions.ManageDataCenter>`
+are allowed to access the data center and also to use the upload page. On this page they can see a long table of available batch processors. The table lists required, optional and non-schema fields (see below) for each processor. It also provides a CSV file template which can be filled and uploaded to avoid header errors.
+
+Data center managers can upload any kind of CSV file from their local computer. The uploader does not check the integrity of the content but the validity of its CSV encoding (see :py:func:`check_csv_charset<waeup.kofa.utils.helpers.check_csv_charset>`). It also checks the filename extension and allows only a limited number of files in the data center.
+
+.. autoattribute:: waeup.kofa.browser.pages.DatacenterUploadPage.max_files
+
+If the upload succeeded the uploader sends an email to all import managers (users with role :py:class:`waeup.ImportManager<waeup.kofa.permissions.ImportManager>`) of the portal that a new file was uploaded.
+
+The uploader changes the filename. An uploaded file ``foo.csv`` will be stored as ``foo_USERNAME.csv`` where username is the user id of the currently logged in user. Spaces in filename are replaced by underscores. Pending data filenames remain unchanged (see below).
+
+After file upload the data center manager can click the 'Process data' button to open the page where files can be selected for import (**import step 1**). After selecting a file the data center manager can preview the header and the first three records of the uploaded file (**import step 2**). If the preview fails or the header contains duplicate column titles, an error message is raised. The user cannot proceed but is requested to replace the uploaded file. If the preview succeeds the user is able to proceed to the next step (**import step 3**) by selecting the appropriate processor and an import mode. In import mode ``create`` new objects are added to the database, `in `update`` mode existing objects are modified and in ``remove`` mode deleted.
+
+Stage 2: File Header Validation
+===============================
+
+Import step 3 is the stage where the file content is assessed for the first time and checked if the column titles correspond with the fields of the processor chosen. The page shows the header and the first record of the uploaded file. The page allows to change column titles or to ignore entire columns during import. It might have happened that one or more column titles are misspelled or that the person, who created the file, ignored the case-sensitivity of field names. Then the data import manager can easily fix this by selecting the correct title and click the 'Set headerfields' button. Setting the column titles is temporary, it does not modify the uploaded file. Consequently, it does not make sense to set new column titles if the file is not imported afterwards.
+
+The page also calls the `checkHeaders` method of the batch processor which checks for required fields. If a required column title is missing, a warning message is raised and the user can't proceed to the next step (**import step 4**).
+
+Stage 3: Data Validation and Import
+===================================
+
+Import step 4 is the actual data import. The import is started by clicking the 'Perform import' button. This action requires the :py:class:`waeup.importData<waeup.kofa.permissions.ImportData>`. If data managers don't have this permission they will be redirected to the login page.
+
+Kofa does not validate the data in advance. It tries to import the data row-by-row while reading the CSV file. The reason is that import files very often  contain thousands or even tenthousands of records. It is not feasable for data managers to edit import files until they are error-free. Very often such an error is not really a mistake made by the person who compiled the file. Example: The import file contains course results although the student has not yet registered the courses. Then the import of this single record has to wait, i.e. it has to be marked pending, until the student has added the course ticket. Only then it can be edited by the batch processor.
+
+The core import method is:
+
+.. automethod:: waeup.kofa.utils.batching.BatchProcessor.doImport()
+   :noindex:
+
+Stage 4: Post-Processing
+========================
+
+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 browser user interface.
Index: main/waeup.kofa/trunk/docs/source/userdocs/datacenter/intro.rst
===================================================================
--- main/waeup.kofa/trunk/docs/source/userdocs/datacenter/intro.rst	(revision 12869)
+++ main/waeup.kofa/trunk/docs/source/userdocs/datacenter/intro.rst	(revision 12870)
@@ -7,24 +7,80 @@
 ===================
 
-Most web portals store their data in a relational database like PostgreSQL, MySQL or Oracle. A relational database is organized in tables of rows and columns, with a unique key for each row. Each data entity gets its own table. Rows in tables can be linked to rows in other tables by storing the unique key of the row to which it should be linked. This sounds quite simple. Many computer users are familiar with this kind of data storage because they are used to spreadsheet programmes like Excel oder Calc which also organize data in tables.
+Most web portals store their data in a relational database like
+PostgreSQL, MySQL or Oracle. A relational database is organized in
+tables of rows and columns, with a unique key for each row. Each data
+entity gets its own table. Rows in tables can be linked to rows in
+other tables by storing the unique key of the row to which it should
+be linked. This sounds quite simple. Many computer users are familiar
+with this kind of data storage because they are used to spreadsheet
+programmes like Excel oder Calc which also organize data in tables.
+Kofa's persistent data are stored in a native object database designed
+for the Python programming language, the so-called ZODB_. An object
+database stores objects with attributes and not records as rows with
+columns in tables. These persistent objects can hold any kind of
+information in attributes and must not adhere to a specific schema
+like records in tables of a relational database.
 
-Kofa's persistent data are stored in a native object database designed for the Python programming language, the so-called ZODB_. An object database stores objects with attributes and not records as rows with columns in tables. These persistent objects can hold any kind of information in attributes and must not adhere to a specific schema like records in tables of a relational database.
-
-The ZODB_ also supports a hierarchical, treelike storage of objects. Objects can contain other objects if they are declared as containers. Objects are stored like folders and files in a filesystem. This makes the object handling very fast and transparent because we can access objects, or more precisely views of objects, by indicating their path in the database, i.e. by traversing the database tree to the object's location. Furthermore, we are accessing the views of objects through a web browser by entering a URL (Uniform Resource Locator). This publication path corresponds more or less to the traversal path of our objects. In Kofa the path always contains the object identifiers of all objects which are passed when traversing the database tree. Example:
+The ZODB_ also supports a hierarchical, treelike storage of objects.
+Objects can contain other objects if they are declared as containers.
+Objects are stored like folders and files in a filesystem. This makes
+the object handling very fast and transparent because we can access
+objects, or more precisely views of objects, by indicating their path
+in the database, i.e. by traversing the database tree to the object's
+location. Furthermore, we are accessing the views of objects through a
+web browser by entering a URL (Uniform Resource Locator). This
+publication path corresponds more or less to the traversal path of our
+objects. In Kofa the path always contains the object identifiers of
+all objects which are passed when traversing the database tree.
+Example:
 
 https://kofa-demo.waeup.org/students/K1000000/studycourse/100/DCO
 
-is the URL which requests a display view of a course ticket with id ``DCO``. This object is stored in a study level container object with id ``100``, stored in a study course container object with id ``studycourse``, stored in the student container object with id ``K1000000``, stored in the students root container, stored in the root container of the application, stored in the root of the database itself.
+is the URL which requests a display view of a course ticket with id
+``DCO``. This object is stored in a study level container object with
+id ``100``, stored in a study course container object with id
+``studycourse``, stored in the student container object with id
+``K1000000``, stored in the students root container, stored in the
+root container of the application, stored in the root of the database
+itself.
 
-This kind of storage requires that each object gets a unique object identifier (object id) within its container. The id string is visible in the browser address bar. Though it's technically possible for ids to contain spaces or slashes we do not allow these kinds of special characters in object ids to facilitate the readability of URLs.
+This kind of storage requires that each object gets a unique object
+identifier (object id) within its container. The id string is visible
+in the browser address bar. Though it's technically possible for ids
+to contain spaces or slashes we do not allow these kinds of special
+characters in object ids to facilitate the readability of URLs.
 
 Batch Processing
 ================
 
-Administrators of web portals, which store their data in relational databases, are used to getting direct access to the portal's database. There are even tools to handle the administration of these databases over the Internet, like phpMyAdmin or phpPgAdmin to handle MySQL or PostgreSQL databases respectively. These user interfaces bypass the portals' user interfaces and give direct access to the database. They allow to easily import or export (dump) data tables or the entire database structure into CSV or SQL files. What at first sight appears to be very helpful and administration-friendly proves to be very dangerous on closer inspection. Data structures can be easily damaged or destroyed, or data can be easily manipulated by circumventing the portal's security machinery or logging system. Kofa does not provide any external user interface to access the ZODB_ directly, neither for viewing nor for editing data. This includes also the export and import of sets of data. Exports and imports are handled via the Kofa user interface itself. This is called batch processing which means either producing CSV files (comma-separated values) from portal data (export) or processing CSV files in order to add, update or remove portal data (import). Main premise of Kofa's batch processing technology is that the data stored in the ZODB_ can be specifically backed up and restored by exporting and importing data. But that's not all. Batch processors can do much more. They are an integral part of the student registration management.
+Administrators of web portals, which store their data in relational
+databases, are used to getting direct access to the portal's database.
+There are even tools to handle the administration of these databases
+over the Internet, like phpMyAdmin or phpPgAdmin to handle MySQL or
+PostgreSQL databases respectively. These user interfaces bypass the
+portals' user interfaces and give direct access to the database. They
+allow to easily import or export (dump) data tables or the entire
+database structure into CSV or SQL files. What at first sight appears
+to be very helpful and administration-friendly proves to be very
+dangerous on closer inspection. Data structures can be easily damaged
+or destroyed, or data can be easily manipulated by circumventing the
+portal's security machinery or logging system. Kofa does not provide
+any external user interface to access the ZODB_ directly, neither for
+viewing nor for editing data. This includes also the export and import
+of sets of data. Exports and imports are handled via the Kofa user
+interface itself. This is called batch processing which means either
+producing CSV files (comma-separated values) from portal data (export)
+or processing CSV files in order to add, update or remove portal data
+(import). Main premise of Kofa's batch processing technology is that
+the data stored in the ZODB_ can be specifically backed up and
+restored by exporting and importing data. But that's not all. Batch
+processors can do much more. They are an integral part of the student
+registration management.
 
 .. note::
 
-  Although exporters are part of Kofa's batch processing module, we will not call them batch processors. Only importers are called batch processors. Exporters produce CSV files, importer process them.
+Although exporters are part of Kofa's batch processing module, we will
+not call them batch processors. Only importers are called batch
+processors. Exporters produce CSV files, importer process them.
 
 
Index: main/waeup.kofa/trunk/src/waeup/kofa/applicants/batching.py
===================================================================
--- main/waeup.kofa/trunk/src/waeup/kofa/applicants/batching.py	(revision 12869)
+++ main/waeup.kofa/trunk/src/waeup/kofa/applicants/batching.py	(revision 12870)
@@ -87,6 +87,6 @@
 
     In update or remove mode `container_code` and `application_number` columns
-    must not exist. The applicant object is solely localized by
-    `applicant_id` or `reg_number`.
+    must not exist. The applicant object is solely localized by searching
+    the applicants catalog for `reg_number` or `applicant_id` .
     """
     grok.implements(IBatchProcessor)
