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