Ignore:
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:
4 added
4 edited

Legend:

Unmodified
Added
Removed
  • main/waeup.kofa/trunk/docs/source/userdocs/academics.rst

    r13026 r13078  
    128128   :noindex:
    129129
     130.. _certificate:
    130131
    131132Certificate
  • main/waeup.kofa/trunk/docs/source/userdocs/applicants.rst

    r13076 r13078  
    11.. _applicants_section:
    22
    3 Applicants Section :sup:`in progress`
    4 *************************************
     3Applicants Section
     4******************
    55
    6 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.
     6Applicants and students are different entities and stored in
     7different places. Moreover, the students section is completely
     8independent from the applicants section. Kofa can be configured
     9without its `applicants` module but not without its `students`
     10module.
    711
    8 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.
     12Anonymous users can self-register and automatically become
     13applicants (users) of the portal. The number of applicants is not
     14limited and, theoretically, Kofa can host hundredthousands of
     15applicants in various applicants containers. Usually, only a few of
     16them are beeing accepted for studying at the university. Once the
     17application process has ended, admitted applicants are transformed
     18into student records. New student records are created and the data
     19are copied from the applicant records. When this 'student creation'
     20process is finished, the applicant records are dispensable. Aim was
     21to provide an easy way to get rid of the huge batches of applicant
     22records by only one click, in order to keep the database clean and
     23tidy. The process is described further below.
    924
    1025.. note::
    1126
    12   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.
     27  The term 'application' has a double meaning in English. An
     28  'application' in computer sciences stands for a software or web
     29  application. Software developers may get confused by using the term
     30  in a different context. To take this into account, we prefer to
     31  speak of 'applicant' in this documentation, instead of 'application'
     32  although, in the linguistic context, it sometimes makes more sense
     33  to speak of the latter. However, in the user interface (UI) and also
     34  in Python docstrings the term 'application' predominates.
    1335
    14 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
     36Much like students, applicants are also a users of the portal and
     37the applicant object is a user account surrogate, see
     38:ref:`Applicants and Students <applicants_and_students>`. In the
     39following we always refer to the applicant container when talking
     40about an applicant.
     41
     42In contrast to students containers, applicant containers do not
     43contain subcontainers. The only objects they contain are applicant
     44payment tickets (i.e. instances of `ApplicantOnlinePayment`). Thus
     45the hierarchy is flat and not really treelike as the students
     46section. Also, applicants (applicant containers) are stored in
     47different parent containers (instances of `IApplicantsContainer`).
     48There is not one single parent container like in the students
     49section but one container for each application session and
     50application type::
     51
     52  Applicants Section (ApplicantsRoot)
     53  |
     54  +---> ApplicantsContainer
     55        |
     56        +---> Applicant
     57              |
     58              +-----> ApplicantOnlinePayment
     59
     60
     61Interfaces
     62==========
     63
     64.. toctree::
     65   :maxdepth: 3
     66
     67   applicants/interfaces
     68
     69Workflow & History
     70==================
     71
     72.. toctree::
     73   :maxdepth: 3
     74
     75   applicants/workflow
     76
     77Browser Pages
     78=============
     79
     80.. toctree::
     81   :maxdepth: 3
     82
     83   applicants/browser
     84
     85
     86
  • main/waeup.kofa/trunk/docs/source/userdocs/students/browser.rst

    r13076 r13078  
    1616described above.
    1717
     18.. _navigation_bar:
     19
     20Navigation Bar
     21==============
     22
     23
     24
     25
    1826
    1927.. _page_layout:
     
    2634only a static top navigation bar. Students can navigate to the
    2735various display form pages of their record by pulling down the 'My
    28 Data' in the navigation bar.
     36Data' tab in the navigation bar.
    2937
    3038Officers see a double-column theme after logging in. The left column
  • main/waeup.kofa/trunk/docs/source/userdocs/students/interfaces.rst

    r13076 r13078  
    1 .. _interfaces:
     1.. _students_interfaces:
    22
    33Student
Note: See TracChangeset for help on using the changeset viewer.