source: main/waeup.kofa/trunk/docs/source/userdocs/hostels.rst @ 16358

Last change on this file since 16358 was 13276, checked in by Henrik Bettermann, 9 years ago

Fix some typos.

Adjust test so that it can be processed by Sphinx.

File size: 9.9 KB
Line 
1.. _accommodation_section:
2
3Accommodation Section
4*********************
5
6The accommodation section is a built-in hostel management system.
7African universities usually run their own student hostels which are
8built on their huge university campuses. They combine the booking of
9beds with the registration process. There are two major use cases.
10Students either have to book a bed space before they can continue
11with the registration, or they are only allowed to book, if they
12have reached a certain registration state. In the first case, the
13university requires students to stay on campus. They usually have
14enough beds for all of their students and need to fill up the
15hostels. In the second case, bed space is limited. Since
16accommodation on campus is usually very reasonable and much safer
17than on the free market outside, students prefer to stay on campus.
18If bed allocation e.g. requires the payment of school fees, the
19university benefits from bed shortage, because students are forced
20to pay in order to get the highly coveted hostel bed.
21
22From the database's point of view, the accommodation section is a
23container of type `HostelsContainer` with id ``hostels``, which is
24located in the `IUniversity` instance. It contains hostels
25(instances of `IHostel`) which again contain the beds (instances of
26`IBed`).
27
28The :ref:`treelike storage of objects <object_database>` in the
29accommodation section can be figured as follows::
30
31
32  Accommodation Section (HostelsContainer)
33  |
34  +---> Hostel
35        |
36        +---> Bed
37
38Interfaces
39==========
40
41`IHostelsContainer`
42-------------------
43
44The unique hostels container serves also as a configuration object.
45It defines for which academic session booking is enabled. The
46student's `current_session` must match the `accommodation_session`.
47It also defines the booking period and the registration workflow
48states for which booking is allowed, see :ref:`bed_tickets`. The
49only property attribute is `expired` which returns ``True`` if the
50current datetime is within the booking period.
51
52.. literalinclude:: ../../../src/waeup/kofa/hostels/interfaces.py
53   :pyobject: IHostelsContainer
54
55`IHostel`
56---------
57
58The hostels container contains the various `Hostel` objects. Hostels
59are buildings with blocks, floors rooms and beds. When adding a
60hostel, the form page is requesting the hostel's name. The
61`hostel_id` is derived from the name by applying
62:code:`lower().replace(' ','-').replace('_','-')` to it. As usual,
63the id will be omitted in manage forms and can thus not be changed
64after hostel creation.
65
66The add and manage form pages let us define the 'dimensions' of the
67hostel and configure blocks with their assignment to either
68female or male students. And they are requesting the number of
69floors per block as well as the number of rooms per floor. All
70blocks have the same number of floors with a fixed number of rooms
71and a fixed number of beds per room. If beds or even entire rooms do
72not exist on a floor, these beds must be later marked reserved, so
73that they are skipped during the automatic allocation process, see
74below.
75
76.. note::
77
78  Blocks for either female or male students? Does Kofa's hostel
79  management accommodate girls and boys strictly separately? No,
80  it doesn't. Blocks are not necessarily real buildings. They can
81  be used as virtual subunits. If the entire hostel has only one
82  block, then yes, either only female or only male students can be
83  hosted in such a hostel. If two blocks are configured (one for
84  male and one for female students), beds of the same room can be
85  assigned twice, once in Block A and a second time in Block B.
86  Consequently, one bed of such a bed pair must be set 'reserved'
87  (see below) to avoid double allocation. In other words, there is
88  always a trick which allows even such uncommon configurations.
89  Not many universities will allow girls and boys to stay in the
90  same room.
91
92.. literalinclude:: ../../../src/waeup/kofa/hostels/interfaces.py
93   :pyobject: IHostel
94
95Beds can be dedicated to pre-study students, fresh students
96(`entry_session` and the hostels container's `accommodation_session`
97correspond), final-year students (`current_level` and the
98certificate's `end_level` correspond, or is even higher) and
99returning students (non-fresh and non-final-year students). Or they
100can be made bookable for all students (beds without category). The
101latter bed type can be configured but is not being used in the base
102package by
103:py:meth:`getAccommodationDetails<waeup.kofa.students.utils.StudentsUtils.getAccommodationDetails>`,
104the method which determines the appropriate bed type of the
105student.
106
107Usually, not every student can be accommodated in every hostel.
108Faculties are sometimes far apart and do manage their own student
109hostels. These hostels require a 'special handling' in
110:py:meth:`getAccommodationDetails<waeup.kofa.students.utils.StudentsUtils.getAccommodationDetails>`.
111The special handling code must be set on the add and manage form
112pages of hostels.
113
114The interface defines also two schema invariants
115(invariant-decorated methods). These methods validate one or more
116depending schema fields. In our case, the methods take care that
117blocks and beds are not assigned twice.
118
119All the parameters above define the construction rules for beds when
120filling the hostel with beds, which is done by the `updateBeds`
121method described further below.
122
123`IBed`
124------
125
126.. literalinclude:: ../../../src/waeup/kofa/hostels/interfaces.py
127   :pyobject: IBed
128
129The `bed_id` contains the 'coordinates' of the bed. It tells us
130precisely in which hostel, in which block, on which floor and in
131which room the bed can be found. The bed id is composed as follows:
132``[hostel id]_[block letter]_[room number]_[bed letter]``. The room
133number contains the floor level: :code:`room_nr = floor*100 + room`.
134Example: ``hall-1_A_101_C`` means that the bed is located in Hostel
1351, Block A, 1st Floor, Room 101 (or 1) and labelled with 'C'.
136
137The `bed_type` attribute is similarly being constructed. It
138describes which kind of student can be allocated: ``[special
139handling code]_[sex]_[stage]``. Example: ``regular_female_re`` means
140that this bed can be booked by regular female returning students.
141Other stages are: ``fr`` (fresh), ``pr`` (pre-study), ``fi``
142(final-year) and ``all`` (all students).
143
144Beds of each hostel are consecutively numbered (`bed_number`).
145
146Except for `owner`, all attributes of bed objects are being
147determined by the system, no matter if they are property or schema
148field attrributes. They can neither be edited nor imported (there is
149no batch processor for beds). The `owner` attribute contains the
150student id, if the bed is occupied. This attribute is either set by
151Kofa when the student creates a bed ticket (see :ref:`bed_tickets`),
152or can be set via the `BedManageFormPage`, see below. The
153`allowed_owners` schema invariant ensures (1) that the selected user
154exists, (2) that the student's current session corresponds with the
155accommodation session and (3) that the student doesn't reside in
156another bed.
157
158.. _hostels_pages:
159
160Browser Pages
161=============
162
163.. seealso::
164
165   :ref:`Manage Hostel Python Test <test_manage_hostels>`
166
167Update Beds
168-----------
169
170Hostels are empty after creation and configuration. They do not
171contain any bed. The hostel's
172:py:meth:`Hostel.updateBeds<waeup.kofa.hostels.hostel.Hostel.updateBeds>`
173method must be called to fill the hostel with beds according to
174the hostel's configuration parameters. This is done by the
175same-named action of the `HostelManageFormPage`. `Hostel.updateBeds`
176iterates over all block letters, floor levels, room numbers and bed
177letters, which have been configured on the `HostelManageFormPage`.
178In each bed letter iteration loop a bed is added and the `bed_id`,
179`bed type` as well as the consecutive `bed_number` are determined
180and stored with the bed.
181
182As the method's name already promises, it does not only add beds to
183an empty hostel container, but also updates existing beds after
184re-configuration. It does this by removing all empty beds before the
185iteration starts. Occupied beds remain in the hostel but get the bed
186number ``9999``. When iterating over the newly configured blocks,
187floors, rooms and bed letters, Kofa checks first, if the bed belongs
188to the group of remaining beds, which could not be removed because
189they are occupied. If so, the bed type is adjusted and the bed
190number changed. The bed remains occupied by the same student, no
191matter if the student meets the newly configured conditions or not.
192
193It might happen that e.g. a room for male students is converted into
194a room for female students, but a male student still resides in this
195room. This has to be checked and the student has to be relocated
196manually, see :ref:`student_relocation`. Moreover, due to the
197reconfiguration of the hostel, an occupied bed may no longer exist
198or offered for booking. This is then indicated by the bed number
199``9999``. Also these students must be relocated manually.
200
201
202Switch Reservations
203-------------------
204
205Beds can be blocked by switching ther reservation status. The switch
206replaces the stage part of `bed_type` by ``_reserved``. Example:
207``regular_female_re`` becomes ``regular_female_reserved``. Switching
208again, reverts this process.
209
210Reserved beds won't be allocated automatically. The beds remain
211empty during the hostel booking period. Students can only be
212allocated manually to reserved beds, which is done via the
213`BedManageFormPage`, see below.
214
215Release Beds
216------------
217
218Releasing a bed does not simply mean clearing the `owner` attribute
219of the bed object. The student has to be notified that booking has
220been cancelled. This is done by replacing the `bed_coordinates` of
221the student's bed ticket. Instead of the coordinates, the student
222will read: ``-- booking cancelled on <datetime of cancellation> --``.
223
224Manage Bed
225----------
226
227Not many things can be managed on this form page. As mentioned above,
228only the `owner` attribute can be changed by entering a student id.
229The id is being validated by a schema invariant. The manage form
230page cannot be accessed, if a student has aleady been allocated.
231Beds must be released first, before they can be allocated to other
232students.
Note: See TracBrowser for help on using the repository browser.