fix: aliases and capitalization of emails

[SebastianKrupinski]

• Resolves: CalDAV: handle email aliases for users #40891
• Resovles: [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]

❌ 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]

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.

[SebastianKrupinski]

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.

[ChristophWurst]

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]

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]

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]

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.