Feature/visual room browser v4 by odzhychko · Pull Request #8731 · nextcloud/calendar

odzhychko · 2026-08-15T17:38:44Z

Cleaned up version of #8264
Resolves #8724

Before (main)

After

Screencast.From.2026-08-15.20-01-26.mp4

🤖 AI (if applicable)

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

codecov · 2026-08-15T17:41:18Z

Codecov Report

❌ Patch coverage is 96.25000% with 6 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/models/resourceProps.ts	44.44%	4 Missing and 1 partial ⚠️
src/utils/roomFilter.ts	99.15%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

Co-authored-by: Rikdekker <Rikdekker@users.noreply.github.com> Assisted-by: ClaudeCode:claude-opus-5 Assisted-by: ClaudeCode:claude-opus-4.8 Signed-off-by: Oleksandr Dzhychko <hey@oleks.dev>

odzhychko · 2026-08-15T18:08:45Z

@SebastianKrupinski Let me know if you find something with regards to code organization.
@nimishavijay Let me know if you find something with regards to UI/UX.

SebastianKrupinski

Okay I tested this this works kind of:

As mentioned already all the fancy spiting and join does not really work and only works for "Netherlands" style address format.

SebastianKrupinski · 2026-08-17T01:22:01Z

+function isPostalCode(segment: string): boolean {
+	return /^\d{4,6}(\s*[A-Z]{1,2})?$/i.test(segment)
+}


This only matches:

4–6 digit numeric codes (covers most European codes like German 5-digit, or simple numeric formats)
Optionally followed by 1–2 letters, with optional whitespace before them (case-insensitive) — this is specifically the Dutch format (1098 XG)

It does not handle many common formats:

UK postal codes (SW1A 1AA) — letters before digits, doesn't match
Canadian codes (K1A 0B1) — letter-digit-letter pattern, doesn't match
US ZIP+4 (12345-6789) — hyphen not allowed
3-digit codes (some countries) — below the 4-digit minimum

With regards to usage of isPostalCode of deriveBuildingName:

Yeah, it's only a guess. That's why #8734 (incl. nextcloud/server#63244) is prossued.

With regards to usage of isPostalCode in joinAddressSegments for buildRoomLocation lets continue in #8731 (comment)

Are you fine with leaving until we can replace it with the building name from #8734?

SebastianKrupinski · 2026-08-17T01:37:22Z

+function joinAddressSegments(segments: string[]): string {
+	const parts: string[] = []
+
+	for (let index = 0; index < segments.length; index++) {
+		const segment = segments[index]
+		const next = segments[index + 1]
+		// A postal code belongs with its city: "1098 XG, Amsterdam" reads as
+		// "1098 XG Amsterdam" on an envelope, and in a map application.
+		if (next !== undefined && isPostalCode(segment)) {
+			parts.push(`${segment} ${next}`)
+			index++
+			continue
+		}
+
+		parts.push(segment)
+	}
+
+	return parts.join(', ')
+}


We are assuming that the address segments are always in the same order

Region Typical order vs. assumed order

Netherlands (assumed) Building, Street, Postal code, City ✅ matches

Germany/France Street, Postal code + City (one field) no building segment; postal code usually already joined with city

UK Street, Town, County, Postcode (postcode is last) postcode comes after the city, not before

US Street, City, State + ZIP ZIP is bundled with state, not directly adjacent to a bare "city" segment

Japan Postal code first, then Prefecture → City → Ward → Block → Building (largest → smallest, reversed) postal code is first, and the "building" is last

"150-0001, Tokyo, Shibuya, 1-1 Building"
the first segment "150-0001" isn't even matched as a postal code by isPostalCode (it has a hyphen, and starts with 3 digits), so it gets wrongly picked as the "building name" instead of the actual building at the end. the merge only fires when a postal-code-shaped segment is immediately followed by another segment,

"221B Baker Street, London, SW1A 2AA"
"SW1A 2AA" doesn't even match the regex, but even if it did, there's no next segment after it — so no merge happens,

Will be removed with together with buildRoomLocation and tackled in a separate issue.
See #8731 (comment)

Will be removed with together with buildRoomLocation and tackled in a separate issue.

Done 4f1ac33

Separate issue in #8735.

SebastianKrupinski · 2026-08-17T01:49:19Z

+ * @param room Room to build a location for
+ * @return Location string, or null if the room carries no usable address data
+ */
+export function buildRoomLocation(room: RoomOption): string | null {


Inherits all the the flaws already mentioned again.

Also breaks localization with hard coded concatenation

Some background

Why not just put roomBuildingAddress into LOCATION?

A "good" LOCATION should also contain the room name and maybe the room floor.

About current behaviour

When adding a room through the resource search we use the roomAddress. (ResourceList.vue)

addResource({ commonName, email, calendarUserType, language, timezoneId, roomAddress }) { this.calendarObjectInstanceStore.addAttendee({ ... }) this.updateLocation(roomAddress) }

roomAddress is derived in nextcloud/cdav-library (with regards to localization same bad ^^)

roomAddress: { get: () => { const data = [ this.roomBuildingRoomNumber, this.roomBuildingStory, this.roomBuildingAddress, ] return data .filter((value) => !!value) .join(', ') },

Going forward: Good solution

I see these possible good solution in the long term for this problem:

Have the resource provider always provide a "good" roomAddress.

Use a localization string like t('calendar', '{roomBuildingAddress}, {roomBuildingStory} (Room {roomBuildingRoomNumber}', ...)

Use use roomAddress (as in 1.) if provided and fallback to (2.).

Going forward this PR

I will just use roomAddress to be consistant with what happens in ResourceList.vue so that we stay consistently bad 😆

Then we can tackle the problem of "Set a good LOCATION for selected room" in a separate issue.

I will just use roomAddress to be consistant with what happens in ResourceList.vue so that we stay consistently

Done 4f1ac33

odzhychko · 2026-08-17T03:10:22Z

Okay I tested this this works kind of:

Your screenshot looks of. Should look like in the description have you checked out feature/visual-room-browser-v4 (-v4)?

SebastianKrupinski · 2026-08-17T03:23:20Z

Okay I tested this this works kind of:

Your screenshot looks of. Should look like in the description have you checked out feature/visual-room-browser-v4 (-v4)?

Yeah, I think so... but here is another take

odzhychko · 2026-08-17T03:56:18Z

Okay I tested this this works kind of:

Your screenshot looks of. Should look like in the description have you checked out feature/visual-room-browser-v4 (-v4)?

Yeah, I think so... but here is another take

Looks still wrong...

Seating capacity should be indicate In the bottom left and not top right.

Signed-off-by: Oleksandr Dzhychko <hey@oleks.dev>

odzhychko force-pushed the feature/visual-room-browser-v4 branch from 5cebb4a to 48a1ed8 Compare August 15, 2026 17:48

feat(resources): browsable room finder in the room picker dialog

6bbba7a

Co-authored-by: Rikdekker <Rikdekker@users.noreply.github.com> Assisted-by: ClaudeCode:claude-opus-5 Assisted-by: ClaudeCode:claude-opus-4.8 Signed-off-by: Oleksandr Dzhychko <hey@oleks.dev>

odzhychko force-pushed the feature/visual-room-browser-v4 branch from 48a1ed8 to 6bbba7a Compare August 15, 2026 17:59

This was referenced Aug 15, 2026

feat(resources): browsable room finder with availability and dropdown filters #8264

Closed

feat: room browser design #8718

Closed

odzhychko added this to 💌 📅 👥 Groupware team Aug 15, 2026

github-project-automation Bot moved this to 🏗️ In progress in 💌 📅 👥 Groupware team Aug 15, 2026

odzhychko self-assigned this Aug 15, 2026

odzhychko marked this pull request as ready for review August 15, 2026 18:07

odzhychko requested review from GVodyanov, SebastianKrupinski and tcitworld as code owners August 15, 2026 18:07

SebastianKrupinski reviewed Aug 17, 2026

View reviewed changes

odzhychko added 2 commits August 17, 2026 04:41

fixup! feat(resources): browsable room finder in the room picker dialog

4f1ac33

Signed-off-by: Oleksandr Dzhychko <hey@oleks.dev>

fixup! feat(resources): browsable room finder in the room picker dialog

96d842f

Signed-off-by: Oleksandr Dzhychko <hey@oleks.dev>

odzhychko mentioned this pull request Aug 17, 2026

Introduce room-location as standard property for rooms for resource providers #8735

Open

odzhychko requested a review from SebastianKrupinski August 17, 2026 05:15

Region	Typical order	vs. assumed order
Netherlands (assumed)	Building, Street, Postal code, City	✅ matches
Germany/France	Street, Postal code + City (one field)	no building segment; postal code usually already joined with city
UK	Street, Town, County, Postcode (postcode is last)	postcode comes after the city, not before
US	Street, City, State + ZIP	ZIP is bundled with state, not directly adjacent to a bare "city" segment
Japan	Postal code first, then Prefecture → City → Ward → Block → Building (largest → smallest, reversed)	postal code is first, and the "building" is last

Uh oh!

Conversation

odzhychko commented Aug 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Before (main)

After

🤖 AI (if applicable)

Uh oh!

codecov Bot commented Aug 15, 2026

Codecov Report

Uh oh!

odzhychko commented Aug 15, 2026

Uh oh!

SebastianKrupinski left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

odzhychko Aug 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

odzhychko Aug 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

odzhychko Aug 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Some background

About current behaviour

Going forward: Good solution

Going forward this PR

Uh oh!

Choose a reason for hiding this comment

Uh oh!

odzhychko commented Aug 17, 2026

Uh oh!

SebastianKrupinski commented Aug 17, 2026

Uh oh!

odzhychko commented Aug 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

odzhychko commented Aug 15, 2026 •

edited

Loading

odzhychko Aug 17, 2026 •

edited

Loading

odzhychko Aug 17, 2026 •

edited

Loading

odzhychko Aug 17, 2026 •

edited

Loading