Changeset 13075 for main/waeup.kofa/trunk/docs/source

Timestamp:

18 Jun 2015, 08:18:16 (9 years ago)

Author:

Henrik Bettermann

Message:

More docs.

In the documentation we prefer to speak of applicant records and avoid the term application as best as we can.

Location:

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

Files:

• applicants.rst (modified) (1 diff)
• datacenter/logging.rst (modified) (4 diffs)
• index.rst (modified) (1 diff)
• security.rst (modified) (4 diffs)

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

@@ -1 @@
-.. _application_section:
+.. _applicant_section:
 
-Application Section :sup:`in progress`
-**************************************
+Applicant Section :sup:`in progress`
+************************************
+
+Applicants and Students are different entities. Moreover, the student section is completely independent from the applicant section. Kofa can be configured without its `applicants` module but not without its `students` module.
+
+Anonymous users can self-register and automatically become applicants (users) of the portal. The number of applicants is not limited and, theoretically, Kofa can host hundredthousands of applicants in various applicants containers. Usually, only a few of them are beeing accepted for studying at the university. Once the application process has ended, admitted applicants are transformed into student records.  New student records are created and the data are copied from the applicant records. When this 'student creation' process is finished, the applicant records are dispensable. Aim was to provide an easy way to get rid of the huge batches of applicant records by only one click, in order to keep the database clean and tidy. The process is described further below.
+
+.. note::
+
+  The term 'application' has a double meaning in English. An 'application' in computer sciences is understood as a software or web application. Software developers may get confused by using the term in a different context. To take this into account, we prefer to speak of an 'applicant' in this documentation, instead of an 'application' although, in the linguistic context, it sometimes makes more sense to speak of the latter. However, in the user interface (UI) and also in Python docstrings the term 'application' predominates.

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

@@ -158 +158 @@
 
 The creation, editing and removal of applicants containers as well
-as editing application records (applicants) is being logged. Also
+as editing applicant records 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
+has proved useful to get a complete overview over all applicant
 data transactions also in the logfile. In return, Kofa does not
 aditionally log actions of browser pages if a workflow transition is
@@ -186 +186 @@
 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
+applicant record was added some seconds later. The
 `ApplicantManageFormPage` was opened, `reg_number`, `sex`, `course1`
 and `date_of_birth` was edited and the ``start`` transition was
@@ -195 +195 @@
 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
+with the data from the applicant record. Finally, the entire
 applicants container including its content was removed in the same
 transaction, see time diffence between the last two log entries.
@@ -205 +205 @@
 The following example shows a typical Nigerian logfile excerpt for a
 student from the very beginning (student record creation from
-application data) till the first registration of courses at level
+applicant data) till the first registration of courses at level
 100. Such an excerpt can be produced simply by searching for
 ``B1234567`` on the ``students.log`` search page::

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

@@ -7 +7 @@
    install
    academics
+   students
    applicants
-   students
    hostels
    documents

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

@@ -89 +89 @@
    :noindex:
 
-Application Section Permissions
--------------------------------
+Applicant Section Permissions
+-----------------------------
 
 .. autoclass:: waeup.kofa.applicants.permissions.ViewApplication()
@@ -199 +199 @@
    :noindex:
 
-Global Application Section Roles
---------------------------------
-
-Global Application Section Roles are assigned portal-wide (globally)
-but do actually only allocate permissions in the Application Section.
+Global Applicant Section Roles
+------------------------------
+
+Global Applicant Section Roles are assigned portal-wide (globally)
+but do actually only allocate permissions in the applicant section.
 
 .. autoclass:: waeup.kofa.applicants.permissions.ApplicantRole()
@@ -218 +218 @@
 
 Global Student Section Roles are assigned portal-wide (globally) but
-do actually only allocate permissions in the Student Section.
+do actually only allocate permissions in the student section.
 
 .. autoclass:: waeup.kofa.students.permissions.StudentRole()
@@ -249 +249 @@
 strange that some of these 'odd' roles do not give more permissions
 than the user already has due to other roles. Their real purpose is to
-delegate permissions to the students or application section. If a user
+delegate permissions to the students or applicant section. If a user
 has for example the LocalStudentsManager role described below at
 department level, s/he automatically gets the StudentsManager role for