fix(CalDAV): disable both iTip and iMip messages

[SebastianKrupinski]

• Resolves: #Add X-NC-Disable-Scheduling property to allow skipping scheduling deliveries #48528

Summary

Adjusted logic to disable both iTip and iMip messages

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)

[ChristophWurst]

The one-off property is weird to be honest. Let's try to move this into a custom header that's set by the client that pushes the event and doesn't want itip/imip to happen. That feels a bit more idiomatic to the dav world.

[SebastianKrupinski]

Done

[kesselb]

Works as expected.

I wonder why we are using a custom header instead of the Schedule-Reply header¹?
It's implemented just in the line below ;)

Footnotes

1. https://datatracker.ietf.org/doc/html/rfc6638#section-8.1 ↩

[SebastianKrupinski]

Works as expected.

I wonder why we are using a custom header instead of the Schedule-Reply header1? It's implemented just in the line below ;)

Footnotes

1. [datatracker.ietf.org/doc/html/rfc6638#section-8.1](https://datatracker.ietf.org/doc/html/rfc6638#section-8.1) [↩](#user-content-fnref-1-825565710bf1bb8af44042a40c5fd8b0)

I agree, we could reuse this header property but according to the RFC it serves a different purpose...

The Schedule-Reply request header is used by a client to indicate to
   a server whether or not a scheduling operation ought to occur when an
   "Attendee" deletes a scheduling object resource.

So I don't know if using it for custom functionality on event creation is a good idea.

[ChristophWurst]

Agree that it serves a different purpose and may lead to confusion. A custom header for this off-standard behavior sounds better IMO.

[ChristophWurst]

/backport to stable30

[ChristophWurst]

/backport to stable29

[kesselb]

@SebastianKrupinski please rebase, squash the fixup commits and hope for a friendly cypress ;)

[SebastianKrupinski]

/backport to stable28

[SebastianKrupinski]

@SebastianKrupinski please rebase, squash the fixup commits and hope for a friendly cypress ;)

Lol. C'mon you know cypress is never friendly with anyone.