Changeset 13076 for main/waeup.kofa/trunk/docs/source
- Timestamp:
- 19 Jun 2015, 05:49:57 (10 years ago)
- Location:
- main/waeup.kofa/trunk/docs/source
- Files:
-
- 6 edited
Legend:
- Unmodified
- Added
- Removed
-
main/waeup.kofa/trunk/docs/source/developerdocs/api/api_students.rst
r7808 r13076 1 `students` -- Student Section Components Package2 ************************************************ 1 `students` -- Students Section Components Package 2 ************************************************* 3 3 4 4 (see also: :ref:`api-students-modules`) -
main/waeup.kofa/trunk/docs/source/userdocs/applicants.rst
r13075 r13076 1 .. _applicant _section:1 .. _applicants_section: 2 2 3 Applicant Section :sup:`in progress`4 ************************************ 3 Applicants Section :sup:`in progress` 4 ************************************* 5 5 6 Applicants and Students are different entities . Moreover, the student section is completely independent from the applicantsection. Kofa can be configured without its `applicants` module but not without its `students` module.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. 7 7 8 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. … … 10 10 .. note:: 11 11 12 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. 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. 13 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 -
main/waeup.kofa/trunk/docs/source/userdocs/security.rst
r13075 r13076 89 89 :noindex: 90 90 91 Applicant Section Permissions92 ----------------------------- 91 Applicants Section Permissions 92 ------------------------------ 93 93 94 94 .. autoclass:: waeup.kofa.applicants.permissions.ViewApplication() … … 107 107 :noindex: 108 108 109 Student Section Permissions110 --------------------------- 109 Students Section Permissions 110 ---------------------------- 111 111 112 112 .. autoclass:: waeup.kofa.students.permissions.ViewStudent() … … 199 199 :noindex: 200 200 201 Global Applicant Section Roles202 ------------------------------ 203 204 Global Applicant Section Roles are assigned portal-wide (globally)205 but do actually only allocate permissions in the applicant section.201 Global Applicants Section Roles 202 ------------------------------- 203 204 Global Applicants Section Roles are assigned portal-wide (globally) 205 but do actually only allocate permissions in the applicants section. 206 206 207 207 .. autoclass:: waeup.kofa.applicants.permissions.ApplicantRole() … … 214 214 :noindex: 215 215 216 Global Student Section Roles217 ---------------------------- 218 219 Global Student Section Roles are assigned portal-wide (globally) but220 do actually only allocate permissions in the student section.216 Global Students Section Roles 217 ----------------------------- 218 219 Global Students Section Roles are assigned portal-wide (globally) but 220 do actually only allocate permissions in the students section. 221 221 222 222 .. autoclass:: waeup.kofa.students.permissions.StudentRole() … … 249 249 strange that some of these 'odd' roles do not give more permissions 250 250 than the user already has due to other roles. Their real purpose is to 251 delegate permissions to the students or applicant section. If a user251 delegate permissions to the students or applicants section. If a user 252 252 has for example the LocalStudentsManager role described below at 253 253 department level, s/he automatically gets the StudentsManager role for -
main/waeup.kofa/trunk/docs/source/userdocs/students.rst
r13048 r13076 1 1 .. _student_section: 2 2 3 Student Section4 *************** 3 Students Section 4 **************** 5 5 6 6 'Student' is a multi-purpose term in Kofa which may lead to some … … 13 13 14 14 The :ref:`treelike storage of objects <object_database>` in the 15 student section can be figured as follows::15 students section can be figured as follows:: 16 16 17 17 18 Student Section (StudentsContainer)18 Students Section (StudentsContainer) 19 19 | 20 20 +---> Student -
main/waeup.kofa/trunk/docs/source/userdocs/students/browser.rst
r13072 r13076 1 1 .. _students_browser: 2 2 3 Browsing the Student Section4 ============================ 3 Browsing the Students Section 4 ============================= 5 5 6 6 The reader may ask: How do officers and students browse the portal? … … 376 376 377 377 Lecturers cannot access student records directly. They don't have 378 access to the student section. Instead, lecturers go to their course378 access to the students section. Instead, lecturers go to their course 379 379 in the academic section and view or export lists of students who 380 380 attended the course, either in a previous or in the current session. -
main/waeup.kofa/trunk/docs/source/userdocs/students/interfaces.rst
r13072 r13076 308 308 ----------------------- 309 309 310 `IStudentOnlinePayment` instances are called student payment tickets 311 or sometimes only payments. They contain the data which confirm that 312 the student has paid a specific fee. 310 313 `waeup.kofa.students.interfaces.IStudentOnlinePayment` inherits from 311 314 `waeup.kofa.payments.interfaces.IOnlinePayment` and has only two
Note: See TracChangeset for help on using the changeset viewer.