feat(dav): add IRoomMetadata::BUILDING_NAME

[Rikdekker]

• Resolves: #

Summary

Adds IRoomMetadata::BUILDING_NAME — a metadata key for the name of the building a room is in.

OCP\Calendar\Room\IRoomMetadata has keys for where a room is, but not for which building it belongs to:

BUILDING_ADDRESS     = '{http://nextcloud.com/ns}room-building-address'
BUILDING_STORY       = '{http://nextcloud.com/ns}room-building-story'
BUILDING_ROOM_NUMBER = '{http://nextcloud.com/ns}room-building-room-number'

Any client that wants to group rooms per building therefore has to derive a building name from the free-form address, in practice by taking everything before the first comma.

That guess fails on real data. On our test instance 51 of 113 rooms have an address whose first segment is empty, so the guess lands on the postal code instead: 32 rooms group under a building called "3511 EP" and 19 under "1098 XG". Neither is a building.

This is not hypothetical. nextcloud/calendar#8264 adds a browsable room finder to the Calendar room picker that groups rooms per building, and it has to carry exactly that heuristic — including a special case to skip postal-code segments — purely because there is no field to read. Every other client that wants to group rooms will reinvent the same guess.

Room backends often do know the building name as a separate value. Exchange and Microsoft 365 room mailboxes expose Building as its own property on Get-Place, and other room backends store it separately from the address. The information exists; there is just no agreed key to publish it under.

The change is one constant, placed alongside the existing building keys:

/**
 * The name of the building this room is located in
 *
 * @since 35.0.0
 */
public const BUILDING_NAME = '{http://nextcloud.com/ns}room-building-name';

Interface-only. No behaviour change and nothing to migrate: IRoomMetadata documents keys that backends may provide, and its docblock already states that backends are not limited to this list. Backends that have a building name publish it; clients that do not know the key ignore it.

Alternatives considered

• Keep deriving it from the address. The status quo, and what produces "3511 EP" as a building name. It also pushes the same heuristic into every client independently.
• Let each backend invent its own key. Backends can already do this, but without a shared key no two backends agree on a name and clients cannot rely on any of them.
• Parse the building out of BUILDING_ADDRESS server-side. That centralises the guess instead of removing it, and still cannot recover a name that was never in the address.

TODO

• Add the constant with a @since matching current master (35.0.0)

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI

[SebastianKrupinski]

Hi @Rikdekker

Can you put the original PR template back in the description and fill it in, instead of replacing it.

[SebastianKrupinski]

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

[Rikdekker]

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.

[Rikdekker]

Done — template restored and filled in, with the rationale moved into the Summary section instead of replacing it. Sorry for the noise.

Two notes on the checklist:

• No tests: the change is a single public constant, so there is no behaviour to cover. Happy to add something if you would rather see it.
• I left the label and milestone boxes unticked since I cannot set those myself.

I also ticked the AI box: the commit carries an Assisted-by trailer.