Introduction of booking confirmations

1 Initial Problem

At the moment we are still working with analog papers and signatures for our students when they want to book any kind of equipment. We can not use the booking tool, because we need a signature and a confirmation for the student to be able to book something. In case someone wants to book something that has just been given out at our in-house Servicedesk there is no way to actually synchronize our online and analog way of booking.

For that we are making a request to add a few features to the booking tool. In order to be able to guarantee that students have been authorized to borrow equipment and that the student who reserved the equipment also picks it up in person, we want to introduce bookings on request. 

2 Conceptual Summary

The user should be able to reserve an object. It is important that we have items that can be booked by the user directly and that we have the possibility to mark an item as "needs to be approved by an administrator before booked".

The option is to be introduced as a setting for booking objects.

In order to be able to recognize at first glance for which booking object the bookings have to be confirmed, the table in the "Booking Objects"-tab is extended by the column "Status". The status column can display the following statuses:

• Direct booking
• Booking request required

If the setting "Booking Confirmation" is enabled for a booking object, the entry "Request booking" is displayed in the action menu of the booking object.

If users click on this entry, the booking is requested. Users will receive a confirmation email with their booking request.

• The booking of room 102 was requested on 12/21/2020.

After users click on "Request Booking", they will be shown the "normal" booking process. They select the desired time slots in the week view and then confirm their booking request.

As soon as someone request a booking an booking object no other user should be able to request a booking.

Only after an administrator has confirmed the booking, the booking is completed

For booking objects that needs to be confirmed we need a certain page on the booking tool where administrators can see what still needs to be approved and to approve the booking.
For administrators, the "Reservations" tab is divided into the "Own Reservations" and "Manage Reservations" sub-tabs.

The "Own Reservations" tab displays reservations made by the administrator.

The "Manage Reservations"-tab lists all reservations of the booking tool. In the "Status"-column, the status of the reservation is displayed.

• If the "Booking confirmation"-option was not activated, only "booked" is displayed here.
• If the "Booking confirmation"-option is enabled, the statuses "Booking requested", "Booking confirmed" and "Booking rejected" can be displayed.

Depending on the status of a booking, different options are offered in the Actions menu in the Actions column.

• Booking requested: Confirm Booking, Reject Booking
• Booking confirmed: Cancel Reservation, Delete
• Booking rejected: Reopen Booking Request, Delete

The new statuses are added to the "Status" filter option of the reserve overview.

In addition, the user must see a page with an overview of all booking objects that the user has requested and/or booked.
Users will not see the sub-tabs. Only the "Reservations"-tab is displayed to them. The "Status"-column is added to the table. The status messages correspond to those of the "Manage Reservations"-sub-tab.

• "Booked", "Booking requested", "Booking confirmed" and "Booking rejected" can be displayed.

Actions for users are extended with "Cancel booking request" for a requested booking.

For all of this to work we need automatic notifications to be sent out on certain situations: 

1. When a user request a booking:
   • User: The booking of room 102 was requested on 12/21/2020.
   • Administrator: User XY has requested to book room 102 on 12/21/2020.
2. When a booking object has been marked as "booked/rejected" by an administrator:
   • User: The booking request for room 102 dated 21.12.2020 has been confirmed/rejected by Adminitrator XY.
3. When a reservation was cancelled the user receives an email with an explanation.
   • User: The reservation of room 102 on 12/21/2020 has been cancelled. The room is no longer available.
4. When users have physically picked up the booking object.
   • User: You have borrowed XY on 21.12.2020. Your loan ends on 21.12.2020.

In order to configure whether users can activate or deactivate notifications themselves, the sub-tab "Notifications" is introduced in Booking Tools.

Comparable to other ILIAS objects (e.g. forum) the following options can be selected:

• Members have to manually activate notifications
• Members will be notified automatically
• Members are notified automatically. Deactivating notifications can be allowed for each member individually.

Accordingly, the cron job "Send Booking Tool Notifications " is introduced.

3 User Interface Modifications

3.1 List of Affected Views

• Booking Tool > "Booking Object"-Settings
• Booking Tool > "Booking Objects"-Tab
• Booking Tool > "Reservations"-tab
• Booking Tool > "Reservations"-tab > "Own Reservations"-sub-tab (NEW)
• Booking Tool > "Reservations"-tab > "Manage Reservations"-sub-tab (NEW)

3.2 User Interface Details

See Mockups above

3.3 New User Interface Concepts

none-

4 Technical Information

{The maintainer has to provide necessary technical information, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues.}

5 Privacy Information

{ Please list all personal data that will need to be stored or processed to implement this feature. For each date give a short explanation why it is necessary to use that date. }

6 Security Implications

{ Does the feature include any special security relevant changes, e.g. the introducion of new endpoints or other new possible attack vectors. If yes, please explain these implications and include a commitment to deliver a written security concept as part of the feature development. This concept will need an additional approvement by the JourFixe. }

7 Contact

• Author of the Request: Hackfort, Marvin [m.hackfort], Zenzen, Enrico [ezenzen]
• Maintainer: Killing, Alexander [alex]
• Implementation of the feature is done by: {The maintainer must add the name of the implementing developer.}

8 Funding

If you are interest in funding this feature, please add your name and institution to this list.

• Katholische Hochschule Nordrhein-Westfalen

9 Discussion

JourFixe, ILIAS [jourfixe], 22 FEB 2021: We highly appreciate this suggestion and accept the feature for ILIAS 8. Please try to improve the title of the request and make it fitting better to what is realy implemented. It would be great to have a perma link in the notification mail that re-directs straight to the reservation screen (admins will be thankful for it). And please consider for a future request to support tasks as well. Having one or more reservations to accept or deny could be one task in my task list.

Hackfort, Marvin [m.hackfort], 1. June 2024: We started the suggestion but the funding required to develop this was too high, so we abandoned the idea on our end. 

10 Implementation

{The maintainer has to give a description of the final implementation and add screenshots if possible.}

Test Cases

Test cases completed at {date} by {user}

• {Test case number linked to Testrail} : {test case title}

Approval

Approved at {date} by {user}.