Calendar

Visualise scheduled activities across day, week, and month views with owner filtering and secure iCal feeds.

Overview#

The Calendar is a full-page scheduling view over the Activities module. It plots every scheduled activity onto a day, week, or month grid, colour-coded by owner, and lets you add, view, edit, and complete activities directly from the page without losing your place. It does not introduce a new entity — every event is an activity, and all changes flow through the same write path and permissions as the activities list.

Route: /calendar

Access to the calendar is gated on the activities.access permission. Users without it do not see the Calendar in navigation and cannot open the page.

Calendar and planning surfaces#

Signals has several date-based views. They share records where appropriate, but they answer different planning questions:

See Using the Rental Diary and Timeline, Rental Diary, Equipment Availability, and Scheduling for those specialist views.

Views#

A view switcher in the toolbar toggles between three layouts. The selected view is remembered in the URL, so a calendar link can be shared with its view, date, and filters intact.

In Day and Week views, events are positioned on a pixel hour-axis for Fantastical-style precision. The visible hour window defaults to your configured working hours and automatically expands to include any event that starts or ends outside that window, so nothing is ever clipped. Completed and cancelled activities render in a muted (greyed) style.

All-day events#

Activities have no explicit "all-day" flag. An activity is treated as all-day when it starts at 00:00 and either has no end time or ends at 23:59 (or the following midnight). All-day events render in a band above the hour grid in Day and Week views, and as chips in Month view.

Navigation & Start Date#

The toolbar provides movement controls:

• Today — jumps the calendar back to the current date.
• Previous / Next — step backwards or forwards by one day, week, or month depending on the active view.
• Date picker — pick any start date. The calendar defaults to today and looks forwards.

The start date drives the visible range: Day shows that single day, Week shows the week containing it, and Month shows the month containing it.

Owner Filter#

Activities are owned by a system user (the owner is the swimlane axis in Day view and the colour axis in Week and Month views). A filter in the toolbar lists active staff users; selecting one or more owners restricts the calendar to their activities. With no selection, all active staff are shown. Owner colours are assigned deterministically per user, so the same person keeps a consistent colour across column headers, event blocks, chips, and avatars.

Note: Filtering is by owner (staff) only. Activity participants are clients, not staff, and are not part of the calendar filter.

Adding, Viewing & Editing Activities#

All create, view, edit, complete, and delete actions happen in modals on the calendar page. Each write reuses the existing Activity actions, so the same validation, authorisation, audit logging, and webhook events apply as anywhere else in the system. After any change, the calendar refreshes locally and instantly — no page reload, no websockets.

Adding an activity#

• Click an empty slot in Day or Week view to open the add modal pre-filled with the slot's owner and start time.
• Click a day-cell in Month view to open the add modal pre-filled with that date.
• The add modal reuses the standard activity form. On save, the new event appears immediately.

Viewing an activity#

Click any event to open a detail modal showing the activity's title, type, status, owner, time, and location. From the modal you can:

• Complete the activity (if you have activities.complete).
• Edit the activity (opens the edit modal).
• Delete the activity (if you have activities.delete).
• Open the full activity page at /activities/{id} via a link.

Editing an activity#

The edit modal uses the same form as create and is reached from the detail modal's Edit action. Saving updates the event in place.

Unscheduled Tray#

Activities with no start time cannot be placed on the grid. They are listed in a collapsible Unscheduled tray alongside the calendar. Click any item in the tray to open its detail modal, from where it can be edited (for example, to give it a start time) and so moved onto the calendar.

Settings That Affect the Calendar#

The calendar honours several existing preferences and scheduling settings for display behaviour. iCal feed URLs are managed on the dedicated Settings → Calendar page (/settings/calendar) — described in Subscribing to the iCal Feed below — but there is no separate screen for scheduling-behaviour configuration.

The visible hour window always auto-expands beyond the configured working hours if an event falls outside them, so events scheduled before or after working hours remain visible.

Subscribing to the iCal Feed#

The calendar can be subscribed to from any iCalendar-compatible client (Google Calendar, Apple Calendar, Outlook). Two feed types are available:

• Global feed — every scheduled activity in the system, plus every non-cancelled resource assignment. Because it mixes everybody together, each entry's title is prefixed with the name it belongs to in square brackets: [Jane Smith] Site visit for an activity, [Acme Crew] R-1001 — Summer Festival for a resource assignment. An activity with no owner gets no prefix.
• Per-user feed — only the activities owned by a specific user, plus the resource assignments for that user's linked account. Titles are plain — everything in the feed already belongs to one person.

Each feed link is created explicitly for one scope: your personal feed, the global feed, or a selected staff member’s feed. Links contain a private credential and an expiring signature, and expire after 90 days. Activities from one year ago up to any point in the future are included (there is no upper bound), subject to the issuing user’s current permissions; resource assignments also require assignment view permission and current warehouse access.

What each entry contains#

Both feeds carry the same detail, so an external calendar shows more than a bare title:

Resource-assignment entries carry the rental number and title as their summary, the venue as LOCATION, and the service, status, and source in DESCRIPTION.

From the calendar page#

A feed button on the calendar opens the feed controls. Users with activity access and view permissions can create a personal link. Administrators and owners can additionally create global or per-staff links. Each link belongs to the user who creates it; simply opening the controls does not create a link.

From Settings → Calendar#

Route: /settings/calendar

The settings page provides the same controls for each scope you can manage:

• Create link generates a private subscribe URL. Copy it into your calendar client’s "subscribe by URL" option while it is shown; the URL cannot be retrieved after leaving the page.
• Download .ics downloads a snapshot using the newly created link.
• Rotate link replaces the credential and immediately disables the previous URL. Update your calendar subscription with the new URL.
• Revoke link immediately disables that scope’s current link without creating a replacement.
• The expiry date is shown for each active link. Create a replacement and update the subscription before its 90-day expiry.

Security note: Treat feed links as private credentials. Every request rechecks the credential, expiry, issuing user’s active status and current access, plus administrative authority and target staff eligibility where applicable. These checks also run before a conditional request can return 304 Not Modified. Rotation and revocation affect the selected scope for that issuer; they do not require rotating APP_KEY. Feed requests are limited to 60 per minute per client IP (or signed-in user), shared across both feed routes; excess requests return 429 with Retry-After. Old signed-only URLs no longer work: existing subscriptions must be re-created using a new link. See the upgrade note.

Permissions#

The calendar introduces no new permissions. It reuses the existing activities.* permissions.