Feature Wiki

Information about planned and released features

Tabs

Custom (User Defined) Booking Data

1 Initial Problem

Often times in the process of booking a resource there is the need to gather additional information relevant to the reservation. For instance, when booking a room, the owner of the booking pool (normally the person responsible for the room), wants to know the reason for the reservation, like "seminar", "workshop", "conference meeting" etc.

There is no way at the moment to gather this information during the booking process in ILIAS booking pools.

2 Conceptual Summary

To solve this problem Custom (User Defined) Booking Data is implemented. The workflow is similar to creating user defined metadata, but the Custom Booking Data is connected to reservations (bookings) of these objects. Custom Booking Data will be gathered by ILIAS during the booking process and will be provided by the user booking an object (by filling out the Custom Booking Data Fields presented by ILIAS during the booking process).

All Custom Booking Data is created mandatory for all reservations, meaning there is no relation of a Custom Booking Data set to a specific booking object. In case different data has to be gathered for different object types, these object types should be seperated with booking pools (basically: don't mix rooms with beamers in one and the same booking pool).

Custom Booking Data can be added to the reservation table (same as with User Defined Metadata) for display/export. Addionally we can create a new "Details" screen for reservations where Custom Booking Data is displayed.

Workflow:

  1. User creates a new data set for Custom Booking Data
  2. User creates data fields for the new data set (Selection Lists, Text Fields etc., see User Defined Metadata)
  3. During the booking process of an object, ILIAS will prompt the user to fill out the Custom Booking Data Fields (Booking Confirmation Screen)
  4. Custom Booking Data can be added to the reservations list (additional columns)
  5. Custom Booking Data can be viewed on a new screen "Details" of a given reservation

3 User Interface Modifications

Please note: The confirmation screen has to be changed for both modes of booking pools: schedule based pools and pools without a time based schedule. In case no schedule is used, the booking confirmation will have to prompt the user to provide the Custom Booking Data, too.

3.1 List of Affected Views

Modified:

  • Booking Pool -> Booking Objects
  • Booking Pool -> Reservations
  • Booking Pool -> Booking Confirmation
New:
  • Booking Pool -> Reservations -> Details View (for a selected reservation)
  • Booking Pool -> Booking Objects -> Sub-Tab: Custom Booking Data

3.2 User Interface Details

Custom Booking Data - View Data Sets
Custom Booking Data - View Data Sets
Custom Booking Data - Create Data Set
Custom Booking Data - Create Data Set
Custom Booking Data - Edit Fields
Custom Booking Data - Edit Fields
Custom Booking Data - Edit Selection Field
Custom Booking Data - Edit Selection Field
Custom Booking Data -5 Edit Text Field
Custom Booking Data -5 Edit Text Field
Custom Booking Data - Booking Confirmation 1 Timeslot
Custom Booking Data - Booking Confirmation 1 Timeslot
Custom Booking Data - Booking Confirmation N Timeslots
Custom Booking Data - Booking Confirmation N Timeslots
Custom Booking Data - Reservation View + Action menue
Custom Booking Data - Reservation View + Action menue
Custom Booking Data - Reservation View Details Modal
Custom Booking Data - Reservation View Details Modal

3.3 New User Interface Concepts

None. In terms of UI this concept is based on the already existing User Defined Metadata.

4 Technical Information

Killing, Alexander [alex], 5 Nov 2019:

  • Custom metadata must always be defined under the meta data tab using the existing screens. So similar to booking objects metadata, reservation metadata should be defined at this location. We then need a way to acticate sets for booking reservations and booking objects separately.
  • As far as I understand the feature we cannot combine/collect this kind of metadata with the Booking Tool: Indicating Preference feature. So in this case no reservation metadata will be collected.

5 Contact

  • Author of the Request: Sesterhenn, Fabian [sesterhenn]
  • Maintainer: {Please add your name before applying for an initial workshop or a Jour Fixe meeting.}
  • Implementation of the feature is done by: {The maintainer must add the name of the implementing developer.}

6 Funding

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

7 Discussion

Killing, Alexander [alex], 5 Nov 2019: I support the feature in general, please see my notes under Technical Information.

Kunkel, Matthias [mkunkel], 31 JAN 2020 : On the first mockup above we see the interface for creating custom metadata sets already known from other components. So this streamlined. But I wonder if we really need several metadata sets for the booking tool or if we could skip this step somehow to ease the workflow. Users often complaining about too much clicks in ILIAS to get to the result (related to the fact that flexibility creates complexity).
And why don't we use modals for the confirmation processes? This would prevent reloading the entire screen again. And modals could are perfectly made for confirmation screens.

JourFixe, ILIAS [jourfixe], 03 FEB 2020 : We highly appreciate this suggestion and schedule the feature for 7. Offering only one metadata set for reservations would need a bigger change in the custom metatdata service and introduce a single exeption. Therefore we reject this suggestion by Matthias. Changing the confirmation screen to modals needs also a lot of additional work due to the complexity of these screens. So modals are rejected as well. Creating and editing the metadata for reservation should be moved to the Metadata tab.

8 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}.

Last edited: 3. Feb 2020, 16:02, Kunkel, Matthias [mkunkel]