Skip to content

Session clashes

Introduction

Sessions are created by multiple users and can have any attendees, room links, guides and dates. This can result in clashes across these many different areas. The system tried to cater for these clashes by indicating when there are clashes and what area of the sessions are clashing.

Clashes

When two sessions are created with an over-lapping time period, the following areas can clash:

  • Attendees: They can both share one or more attendees
  • Guides: They can both share one or more guides
  • Facilitators: They can both share one or more facilitators
  • Convenor: They can both share the same convenor
  • Link: They can both share the same meeting link

Two sessions overlap when:

  • The start time of one session is before the end time of the other session AND
  • The end time of the one session is after the start time of the other session

We can assume this as it is given that the start time of a session is before the end time of a session.

ClashResource

The ClashResource is used to display all clashes in the system.

On this view the admin can filter by:

  • Type of clash

Clash Service

To centralise the session clash business logic we use a dedicated ClashService class. This service performs the following functions:

  • Determine if a single session has a clash
  • Run through all sessions and determine if there are any clashes
  • Store a clash record
  • Check if a specific clash still exists
  • Run through all clashes to see if they still exist

Clash table

In order to keep track of clashes in a helpful way, we use a dedicated table to store and track clashes.

The table structure is:

  • ID
  • engauge_session_id: The id of the first session that has the clash
  • clash_session_id: The id of the second session that has the clash
  • type: The type of clash that it is: attendee, guide, facilitator, convenor, link
  • attendee_id: The id of the attendee that is being clashed
  • guide_id: The id of the guide that is being clashed
  • facilitator_id: The id of the facilitator that is being clashed
  • convenor_id: The id of the convenor that is being clashed
  • link: The link that is being clashed

Clash Sources

It's important to note where clashes can originate from:

  • Session Creation
  • Session Editing
  • Session Deletion

Clash update listener

To keep track of clashes, we use a dedicated CheckSessionClashes listener. This listener listens for the following events:

  • EngaugeSessionUpdated

Clash removal handling

When a session is deleted, we need to remove all clashes that are associated with that session. This is done by listening for the EngaugeSession boot event and removing all clashes that are associated with that session on the deleting event.