Skip to content

feat(dav): add IRoomMetadata::BUILDING_NAME #63244

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Rikdekker wants to merge 1 commit into
base: master
Choose a base branch
from
+11 −0
Open

feat(dav): add IRoomMetadata::BUILDING_NAME #63244

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions lib/public/Calendar/Room/IRoomMetadata.php
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -37,6 +37,17 @@ interface IRoomMetadata {
*/
public const CAPACITY = '{http://nextcloud.com/ns}room-seating-capacity';

/**
* The name of the building this room is located in
*
* Clients group rooms by building. Without this key they have to guess a
* building from BUILDING_ADDRESS, which only works for backends that
* happen to put the building name first.
*
* @since 35.0.0
*/
public const BUILDING_NAME = '{http://nextcloud.com/ns}room-building-name';

@SebastianKrupinski SebastianKrupinski Aug 14, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, So you are adding a dav property. But where is the implementation of this?

@Rikdekker Rikdekker Aug 14, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question — there is no implementation to add here, because the metadata pipeline is already generic.

AbstractPrincipalBackend stores whatever keys a backend returns from IRoom::getAllAvailableMetadataKeys() in calendar_rooms_md, and searchPrincipalsByMetadataKey() handles arbitrary keys in its default branch. Only FEATURES and CAPACITY need special cases, because they are a list and a numeric range rather than a plain string. BUILDING_ADDRESS, BUILDING_STORY and BUILDING_ROOM_NUMBER have no implementation either — they are defined in IRoomMetadata and nowhere else in server, and reach clients through that generic path. BUILDING_NAME behaves exactly the same.

So this PR is a shared vocabulary entry rather than a feature: without it, backends and clients cannot agree on a key name for something both sides already have.

Producer — RoomVox 1.3.0 publishes this property today. It holds the building as its own field, so it can emit the real name instead of leaving clients to guess. It currently uses the literal string, since there is no constant to reference; if this lands, that becomes IRoomMetadata::BUILDING_NAME with no change to the key itself.

Consumer — nextcloud/calendar#8264 adds a room browser to the Calendar room picker that groups rooms per building. It currently derives the building name from BUILDING_ADDRESS by taking the segment before the first comma, plus a special case to skip postal codes. That heuristic exists purely because there is no key to read, and it is wrong often enough to matter: on a 113-room instance, 51 rooms group under a postal code instead of a building.

Happy to open a follow-up on the Calendar side that prefers BUILDING_NAME when a backend supplies it and keeps the address heuristic as a fallback — that felt like it belonged in a separate PR rather than this one.


/**
* The physical address of the building this room is located in
*
Expand Down
Loading