Improve calendar event relations: filtering and access to linked event properties

[matt-ek]

Is your feature request related to a problem? Please describe.

Nextcloud Tables already allows relation columns to link a row to calendar events. This is a very useful integration, but it becomes difficult to use in practice when a user has access to many calendars and many events.

Currently, there is no practical way to restrict the list of selectable events, for example by:

• calendar
• date range
• future or past events
• current week or month
• next X days

With many shared calendars, the event picker can therefore contain a very large number of unrelated events. Finding the correct event becomes cumbersome and, in larger installations, almost impractical.

There is also a second limitation: after linking an event, Tables can reference the event itself, but cannot easily expose properties of that linked event.

For example, useful information already available in Calendar includes:

• start date
• start time
• end date
• end time
• location
• calendar
• description

At the moment, this information has to be entered again manually into separate table columns if it is needed there. This creates duplicated data and can lead to inconsistencies when the calendar event changes.

Describe the solution you'd like

I would suggest extending relations to calendar events in two areas.

1. Filtering of selectable calendar events

When configuring a relation column that links to calendar events, it should be possible to define filters for the available events.

Possible filters could include:

• one or more selected calendars
• future events only
• past events only
• today
• current week
• current month
• next X days
• custom date range

For example:

Relation source: Calendar events
Calendars: Events, Church Services
Time range: Today to +90 days

The event picker should then only show events matching these criteria.

This would make the existing event relation much more usable, especially in installations where users have access to many shared calendars.

2. A field type for properties of a linked object

It would also be very helpful to introduce a column type that can display a specific property of an existing relation.

For example:

Column type: Related property
Relation column: Event
Property: Start date

Other possible properties for calendar events could be:

• start date
• start time
• end date
• end time
• location
• description
• calendar
• organizer
• event UID

These values should ideally be derived dynamically from the linked object and be read-only in Tables.

Example:

Event	Date	Start	Location	Responsible
Community meeting	24.09.2026	19:00	Main hall	John Doe

Only the Event relation would be selected manually. Date, Start and Location would automatically come from the linked calendar event.

Ideally, this concept should not be limited to Calendar. A generic Related property or Relation lookup column could later also expose properties of other object types supported by relations.

Describe alternatives you've considered

The current workaround is to manually copy information from the calendar event into normal Tables columns.

For example, after linking an event, users can manually enter its date, time and location into additional columns.

However, this has several disadvantages:

• information is duplicated
• changes to the original event are not reflected automatically
• data can become inconsistent
• users need to maintain the same information in multiple places
• the benefit of using relations is reduced

Another workaround would be to synchronize Calendar and Tables externally, for example via automation tools or custom API integrations.

For basic information that is already available through an existing relation, this seems unnecessarily complex.

Additional context

This would significantly improve the usefulness of relations in Nextcloud Tables.

A common use case is that Calendar remains the authoritative source for scheduling, while Tables stores additional structured or workflow-specific information around an event.

Examples include:

• event organization
• volunteer coordination
• room and facility management
• meeting tracking
• equipment preparation
• internal task or status tracking

For example, an event could be maintained in Calendar with its date, time and location, while Tables adds fields such as:

• responsible person
• preparation status
• required equipment
• internal notes

In this scenario, users should not have to duplicate the event's date, time and location in Tables.

Filtering would make relations usable at scale, while a generic relation-property lookup would make linked objects much more useful for building applications with Tables.

Together, these two improvements could turn relations from simple object links into a much stronger integration mechanism between Tables and other Nextcloud apps.