fix: aliases and capitalization of emails #52622

SebastianKrupinski · 2025-05-04T21:42:58Z

Resolves: CalDAV: handle email aliases for users #40891
Resolves: [Bug]: iMIP cancellation messages are not propagated to the personal calendar #51115
Also addresses the same scenario on inbound messages [Bug]: Calendar invitations not sent when email addresses contain capital letters #51989

Summary

Added logic to handle system user email aliases
Added logic to handle email addresses in different cases (lower, upper, camel, etc)
Simplified handling logic

Testing

Requires external account for sending meeting invitation updates
Send an initial meeting invitation to a mail account configured on NC
Add the meeting to your calendar
Then send a meeting update from external account
Wait for mail app to sync so that the email is found
Trigger mail background imip service
Meeting should update with new information
(Make sure "Restrict users to only share with users in their groups" (Administration Settings -> Sharing) is off) (There is a unrelated bug that will cause imip processing to fail)

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)

codecov · 2025-05-08T12:33:17Z

❌ We are unable to process any of the uploaded JUnit XML files. Please ensure your files are in the right format.

ChristophWurst

High level feedback

Did not test.

ChristophWurst · 2025-05-15T18:06:23Z

lib/public/Calendar/IHandleImipMessage.php

+	 *
+	 * @deprecated 32.0.0 Use IHandleImip instead
 	 */
 	public function handleIMipMessage(string $name, string $calendarData): void;


This method uses calendar data as string intentionally. It was chosen over a Sabre type to not leak Sabre into the public API.
Having Sabre in the public API means we might be forced to break our own API if Sabre changes.

With Symfony and Doctrine we have seen that. Our own layer of abstraction helps us to work around some of the 3rdparty changes. In rare cases API changes are necessary.

I will leave the decision with you.

I see your point but I don't think this is an issue.

I think the main entry point for iMip (and most other functions) should be the calendar manager (string), and the manager then finds the correct calendar and forwards the request to the calendar it self.

External App -> CalendarManager::handleImip(string) -> Calendar::handleImip(VCALENDAR)

Any external app does not need to know anything about calendar searching or the sabre interface, the only to components that do are the manager and the calendar it self. But if any app does want to work directly with the calendar then it would need to know how to work with Sabre.

I think the benefits of not serializing and de-serializing every time we exit and enter a function, out weight the possibility of having to change our API in the future. I could also wrap the VCALENDAR object in a DTO, but that might be over kill.

This is not the point. The issue is that you make consumers of the Nextcloud OCP API also dependent on Sabre code.

This will be tricky in terms of tooling (Psalm, IDEs) and impose potential breakage should Sabre change.

I can't imagine the serialization to be a real world problem, as we are passing one event at a time. IMO the ics is still the most flexible and framework-agnostic type here.

SebastianKrupinski · 2025-05-21T19:54:18Z

Design Consideration.

The current logic replicates the current imip handling behaviour, that only handles changes to existing events.

But taking in to consideration functionality from other apps, GH and client requests it might be a good idea to modify the CalendarManager::handleImip with a extra flag to create a new event if one does not already exist. aka Automatically adding tentative ivites

@ChristophWurst i'll leave this decision to you.

ChristophWurst · 2025-05-22T10:23:28Z

But taking in to consideration functionality from other apps, GH and client requests it might be a good idea to modify the CalendarManager::handleImip with a extra flag to create a new event if one does not already exist. aka Automatically adding tentative ivites

Let's take baby steps. Fix the alias mismatch in this PR and we look into importing of tentative events in another one.

kesselb · 2025-05-22T17:42:10Z

Thanks 👍

The change to loop over the attendees in handleImip also fixes #51115. Therefore, I have sunsetted #53046. I will check, when you are done here, if it makes sense to port some of the test cases, but most of them were relevant for creating the extra cancellation message, which is not required here.

SebastianKrupinski · 2025-06-03T17:00:44Z

Okay, I've made the calendar interface take a string instead of a vObject.

Can we get this in, please. I want to use this for a new calendar feature instead of the old flow.

@ChristophWurst @kesselb

ChristophWurst · 2025-06-04T07:18:47Z

Could you please explain why the old interface is insufficient and replaced by a new one with almost an identical signature, and how this is a requirement for #40891?

SebastianKrupinski · 2025-07-02T14:12:06Z

Could you please explain why the old interface is insufficient and replaced by a new one with almost an identical signature, and how this is a requirement for #40891?

I've for now removed the new interface so we can back port this for some fixes, but will need to (most likely) make a new interface for an up coming feature, i will need flags to create tentative events.

apps/dav/lib/CalDAV/CalendarImpl.php

ChristophWurst · 2025-07-03T13:13:19Z

lib/private/Calendar/Manager.php

 		}

-		/** @var VEvent|null $vEvent */
-		$eventObject = $calendarObject->VEVENT;


I think the variable still makes sense because it helps Psalm and PHPStorm with the wiggly types of Sabre objects

Sure, we can make it play nice with phpstorm. 😆

Is there a problem with that?

lib/private/Calendar/Manager.php

ChristophWurst · 2025-07-03T13:15:37Z

tests/lib/Calendar/ManagerTest.php

-		$this->assertFalse($result);
-	}
-
-	public function testHandleImipCancelOrganiserInReplyTo(): void {


why did all of these test cases need to go?

Because all the methods just forward to the same method handleIMipCancel() -> handleIMip(). testHandleImipCancelEventNotFound, testHandleImipReplyEventNotFound, testHandleImipRequestEventNotFound is the same test the only reason we had so many of them is because we had separate handling code for each imip type, now there is only one. Also some of the logic was moved to the CalendarImpl.

But I did notice that the test names got renamed in the rebase, so I fixed them.

ChristophWurst

Public API changes seem avoidable

ChristophWurst · 2025-07-04T06:24:31Z

lib/private/Calendar/Manager.php

 		string $recipient,
 		string $calendarData,
 	): bool {
+		$userId = substr($principalUri, 17);


Magic number. Consider replacing it with a strlen of a literal

It's assuming a certain prefix, I guess. I'd really like to see a check here to catch when someone uses the method wrong.

I put in a check for the prefix. The magic number should not be an issue now.

ChristophWurst · 2025-07-04T06:26:19Z

lib/private/Calendar/Manager.php

+		$userId = substr($principalUri, 17);
+		return $this->handleIMip($userId, $calendarData);


As far as I can see it's very well possible to keep the existing methods. Therefore it appears like we are changing public API within just one major version when there is no hard requirement for it.
This is not how we want to build our platform. Even if the three methods introduced in 31 could be simplified, we shouldn't change them just for that purpose.

Removed the deprecation's. There was only one method adding in 31, the rest are 25.

ChristophWurst · 2025-08-06T09:15:24Z

lib/private/Calendar/Manager.php

 		try {
 			/** @var VCalendar $vObject|null */
-			$calendarObject = Reader::read($calendarData);
+			$vObject = Reader::read($message);


tip for future PRs and containing diff sizes: don't rename variables unless there is a good reason for it.

ChristophWurst · 2025-08-06T09:16:06Z

lib/private/Calendar/Manager.php


 	/**
-	 * @since 31.0.0
+	 * @since 32.0.0


nit: don't use since annotations for private API. this gives a wrong sense of public API

ChristophWurst · 2025-08-26T14:03:01Z

@st3iny could you please give this a review 🙏

st3iny

Code changes look mostly like merging all methods into a single one and adding some capitalization logic. Did some IMip testing.

Worked

Regular IMip stuff -> no regressions
Email addresses with inconsistent capitalization (see note below).

Didn't work

Aliases. I sent an invite to the secondary email address of the local user and imported the event. However, any incoming iMip update emails were not propagated to my calendar. The call to $schedulingPlugin->getAddressesForPrincipal(...) returned the whole set, so the scheduling/iTip logic afterwards seems to be wrong.

The mail app will still complain about the capitalization. However, when I manually import the event, the iMip logic will continue to work from there one (despite the Mail app complaining about the capitalization).

(Needs to be fixed there I guess.)

SebastianKrupinski · 2025-08-28T18:37:01Z

@st3iny

Code changes look mostly like merging all methods into a single one and adding some capitalization logic.

Correct

1. Aliases. I sent an invite to the secondary email address of the local user and imported the event. However, any incoming iMip update emails were not propagated to my calendar. The call to `$schedulingPlugin->getAddressesForPrincipal(...)` returned the whole set, so the scheduling/iTip logic afterwards seems to be wrong.

Took a minute to remember what I was thinking when I made this in May. So the logic in this PR was correct, the logic in the ITipBroker was not (the 3rdparty code we use does not check for aliases), I was original going to fix the iTipBroker in a separate PR because I didn't want to refactor to much at once. BUT... I found another way, but swapping the alias email address for the actual address to make the 3rdparty code work as is (not my favorite solution but the best at the moment).

The mail app will still complain about the capitalization. However, when I manually import the event, the iMip logic will continue to work from there one (despite the Mail app complaining about the capitalization).

Correct the mail and calendar app will need more adjustments for both capitalization and aliases

st3iny

Aliases work now.

Signed-off-by: SebastianKrupinski <[email protected]>

lib/private/Calendar/Manager.php

SebastianKrupinski · 2025-08-29T11:54:54Z

@kesselb @kesselb

I was think of backporting this to at least 31. Any objections?

kesselb · 2025-08-31T17:53:21Z

/backport to stable31

SebastianKrupinski added the 2. developing Work in progress label May 4, 2025

SebastianKrupinski self-assigned this May 4, 2025

SebastianKrupinski added this to 💌 📅 👥 Groupware team May 4, 2025

github-project-automation bot moved this to 🏗️ In progress in 💌 📅 👥 Groupware team May 4, 2025

SebastianKrupinski force-pushed the fix/refactor-imip branch from 6402015 to 8759f57 Compare May 8, 2025 12:32

SebastianKrupinski mentioned this pull request May 8, 2025

Calendar invite updates, attendance notifications and cancellations are (still) not working nextcloud/mail#10811

Open

SebastianKrupinski force-pushed the fix/refactor-imip branch 4 times, most recently from e94efdf to 7a614d1 Compare May 10, 2025 22:23

SebastianKrupinski requested a review from ChristophWurst May 15, 2025 16:52

ChristophWurst approved these changes May 15, 2025

View reviewed changes

SebastianKrupinski force-pushed the fix/refactor-imip branch from 5562499 to 584a214 Compare May 21, 2025 18:44

kesselb mentioned this pull request May 22, 2025

handle cancellation message with more than one attendee #53046

Closed

6 tasks

SebastianKrupinski marked this pull request as ready for review June 3, 2025 17:00

SebastianKrupinski requested review from a team, st3iny and tcitworld as code owners June 3, 2025 17:00

SebastianKrupinski requested review from artonge, come-nc and yemkareems and removed request for a team June 3, 2025 17:00

SebastianKrupinski added 3. to review Waiting for reviews and removed 2. developing Work in progress labels Jun 3, 2025

come-nc removed their request for review June 5, 2025 15:32

SebastianKrupinski force-pushed the fix/refactor-imip branch from 76dfffd to 4a958dd Compare July 2, 2025 14:05

ChristophWurst reviewed Jul 3, 2025

View reviewed changes

ChristophWurst requested changes Jul 4, 2025

View reviewed changes

ChristophWurst approved these changes Aug 6, 2025

View reviewed changes

SebastianKrupinski force-pushed the fix/refactor-imip branch from fa56a07 to 8f4abb4 Compare August 26, 2025 16:50

st3iny reviewed Aug 27, 2025

View reviewed changes

SebastianKrupinski force-pushed the fix/refactor-imip branch from f402d5b to f550665 Compare August 28, 2025 18:42

st3iny approved these changes Aug 28, 2025

View reviewed changes

fix: aliases and capitalization of emails

7e92b15

Signed-off-by: SebastianKrupinski <[email protected]>

SebastianKrupinski force-pushed the fix/refactor-imip branch from daf403b to 7e92b15 Compare August 28, 2025 21:40

SebastianKrupinski merged commit 94c80aa into master Aug 28, 2025
210 of 212 checks passed

SebastianKrupinski deleted the fix/refactor-imip branch August 28, 2025 22:30

github-project-automation bot moved this from 🏗️ In progress to ☑️ Done in 💌 📅 👥 Groupware team Aug 28, 2025

kesselb reviewed Aug 29, 2025

View reviewed changes

lib/private/Calendar/Manager.php Show resolved Hide resolved

kesselb mentioned this pull request Aug 29, 2025

[Bug]: iMIP cancellation messages are not propagated to the personal calendar #51115

Closed

backportbot bot added the backport-request label Aug 31, 2025

backportbot bot mentioned this pull request Aug 31, 2025

[stable31] fix: aliases and capitalization of emails #54771

Merged

2 tasks

backportbot bot removed the backport-request label Aug 31, 2025

SebastianKrupinski mentioned this pull request Sep 1, 2025

feat: Meeting Proposals #53831

Merged

4 tasks

nextcloud-bot mentioned this pull request Sep 2, 2025

32.0.0 beta 5 #54796

Merged

st3iny mentioned this pull request Sep 5, 2025

Allow processing of invitations if email address is an alias nextcloud/calendar#4918

Closed

		$userId = substr($principalUri, 17);
		return $this->handleIMip($userId, $calendarData);

Uh oh!

fix: aliases and capitalization of emails #52622

fix: aliases and capitalization of emails #52622

Uh oh!

Conversation

SebastianKrupinski commented May 4, 2025 • edited by kesselb Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Testing

Checklist

Uh oh!

codecov bot commented May 8, 2025

Uh oh!

ChristophWurst left a comment

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!

SebastianKrupinski commented May 21, 2025

Uh oh!

ChristophWurst commented May 22, 2025

Uh oh!

kesselb commented May 22, 2025

Uh oh!

SebastianKrupinski commented Jun 3, 2025

Uh oh!

ChristophWurst commented Jun 4, 2025

Uh oh!

SebastianKrupinski commented Jul 2, 2025

Uh oh!

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!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ChristophWurst left a comment

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

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ChristophWurst commented Aug 26, 2025

Uh oh!

st3iny left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Worked

Didn't work

Uh oh!

SebastianKrupinski commented Aug 28, 2025

Uh oh!

st3iny left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

SebastianKrupinski commented May 4, 2025 •

edited by kesselb

Loading

st3iny left a comment •

edited

Loading