Overview
When there is a timeframe associated to a tracker (hence to artifacts), the email notifications associated to artifacts should contains the needed information so the event can be added to a calendar (outlook, google cal, etc).
It's close to what is proposed when you book a train or a medical appointment.
In order to to work, the tracker must have the following pre-conditions:
- Have the title semantic and title must not be empty
- Have the timeframe semantic and the timeframe must be valid:
- end of time frame must exist
- end of time frame must be greater of equal to beginning of timeframe
- At notification level, there is a configuration option to toggle the "event in notification" feature. This feature is off by default for existing trackers but on by default for new trackers from Tuleap official templates.
The feature should come with extensive logging for sys admin troubleshooting needs.
Behavior
Event content
- When there is a Description semantic, the description is added as Calendart Event description (permissions apply)
- The owner of the event should be
$PLATFORM_NAME - $PROJECT_NAME & associated email is platform's noreply
Cancellation of events
When start date & end date is cleared, it means that the event is canceled
Events with hours information
- when start date & end date are used and both fields are "datetime", the event is sent with hour information. Otherwise the event duration is day long.
- when start date is a datetime and end date is computed with a duration, the event last duration x 24h
- when event is a date time, the associated timezone is the timezone of the server
Events with Yes/No/Maybe
It's not possible to add Yes/No/Maybe options on events in this context because it will generate an email response sent to the event organizer (here noreply). This is called METHOD:REQUEST in ics jargon.
Update of events
Update of events is not supported.
According to the RFC, the only way to support the update of events is with REQUEST type of events:
3.2.2.1. Rescheduling an Event
The "REQUEST" method may be used to reschedule an event. A rescheduled event involves a change to the existing event in terms of its time or recurrence intervals and possibly the location or description. If the recipient CUA of a "REQUEST" method finds that the "UID" property value already exists on the calendar but that the "SEQUENCE" (or "DTSTAMP") property value in the "REQUEST" method is greater than the value for the existing event, then the "REQUEST" method describes a rescheduling of the event.
Granted that we cannot set REQUEST (see upper reason), it's therefore not possible to issue event's update.
Permissions
When notifications are configured to not check permissions, the calendar event is associated to the notification email even if the recipient is not supposed to have access to the timeframe information.
Impact on templates
Project & tracker templates are not modified yet. We should let some time to the feature to see how it behaves in the wild before pushing it everywhere.
Mockups
-
Configure the option in tracker notifications
Scenario
Different Timezone
- Bob is located at Paris (Timezone Europe/Paris)
- Alice is located at New York (Timezone America/NY)
- Bob creates an artifact with start date 2023-11-14 10:00 -> 2023-11-14 11:00 (for his timezone, hence Paris time)
- Bob receive an event that last between 2023-11-14 10:00 and 2023-11-14 11:00 (Paris time)
- Alice receive an event that last between 2023-11-14 04:00 and 2023-11-14 05:00 (NY time)
- Alice modify the artifact to set end date to 2023-11-14 06:00 (NY Time)
- Bob receive an event that last between 2023-11-14 10:00 and 2023-11-14 12:00 (Paris time)
- Alice receive an event that last between 2023-11-14 04:00 and 2023-11-14 06:00 (NY time)
Start date time + duration
Tracker is using start date as date time + duration.
- Bob creates an event that start 2023-11-28 at 10:00 with a duration of 2 days
- The received event last from 2023-11-28 at 10:00 to 2023-11-30 at 10:00