Changeset 13078 for main

Timestamp:

19 Jun 2015, 15:36:49 (9 years ago)

Author:

Henrik Bettermann

Message:

More docs.

Location:

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

Files:

• academics.rst (modified) (1 diff)
• applicants (added)
• applicants.rst (modified) (1 diff)
• applicants/browser.rst (added)
• applicants/interfaces.rst (added)
• applicants/workflow.rst (added)
• students/browser.rst (modified) (2 diffs)
• students/interfaces.rst (modified) (1 diff)

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

@@ -128 +128 @@
    :noindex:
 
+.. _certificate:
 
 Certificate

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

@@ -1 +1 @@
 .. _applicants_section:
 
-Applicants Section :sup:`in progress`
-*************************************
+Applicants Section
+******************
 
-Applicants and Students are different entities and stored in different places. Moreover, the students section is completely independent from the applicants section. Kofa can be configured without its `applicants` module but not without its `students` module.
+Applicants and students are different entities and stored in
+different places. Moreover, the students section is completely
+independent from the applicants 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.
+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 stands for 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 'applicant' in this documentation, instead of '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.
+  The term 'application' has a double meaning in English. An
+  'application' in computer sciences stands for 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 'applicant' in this documentation, instead of '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.
 
-In contrast to student containers, applicant containers do not contain subcontainers. The only objects they contain are applicant payment tickets (i.e. instances `ApplicantOnlinePayment`). Thus it does not make sense to speak of a  treelike structure. In contrast to the students section
+Much like students, applicants are also a users of the portal and
+the applicant object is a user account surrogate, see
+:ref:`Applicants and Students <applicants_and_students>`. In the
+following we always refer to the applicant container when talking
+about an applicant.
+
+In contrast to students containers, applicant containers do not
+contain subcontainers. The only objects they contain are applicant
+payment tickets (i.e. instances of `ApplicantOnlinePayment`). Thus
+the hierarchy is flat and not really treelike as the students
+section. Also, applicants (applicant containers) are stored in
+different parent containers (instances of `IApplicantsContainer`).
+There is not one single parent container like in the students
+section but one container for each application session and
+application type::
+
+  Applicants Section (ApplicantsRoot)
+  |
+  +---> ApplicantsContainer
+        |
+        +---> Applicant
+              |
+              +-----> ApplicantOnlinePayment
+
+
+Interfaces
+==========
+
+.. toctree::
+   :maxdepth: 3
+
+   applicants/interfaces
+
+Workflow & History
+==================
+
+.. toctree::
+   :maxdepth: 3
+
+   applicants/workflow
+
+Browser Pages
+=============
+
+.. toctree::
+   :maxdepth: 3
+
+   applicants/browser
+
+
+

main/waeup.kofa/trunk/docs/source/userdocs/students/browser.rst

@@ -16 +16 @@
 described above.
 
+.. _navigation_bar:
+
+Navigation Bar
+==============
+
+
+
+
 
 .. _page_layout:
@@ -26 +34 @@
 only a static top navigation bar. Students can navigate to the
 various display form pages of their record by pulling down the 'My
-Data' in the navigation bar.
+Data' tab in the navigation bar.
 
 Officers see a double-column theme after logging in. The left column

main/waeup.kofa/trunk/docs/source/userdocs/students/interfaces.rst

@@ -1 @@
-.. _interfaces:
+.. _students_interfaces:
 
 Student