Outlook adapter: support shared/delegated mailboxes via explicit Graph user path

[kai-osthoff]

Problem

The Outlook HTTP adapter currently hardcodes Microsoft Graph URLs below /me/calendars/{calendarID} for all operations:

• list/calendar view
• create
• update
• delete

This prevents using CalendarSync with a shared or delegated Microsoft 365 mailbox when the OAuth principal is a delegate and the calendar belongs to another mailbox. Shared mailboxes commonly have no interactive sign-in of their own.

Reproduction

1. Grant user A access to the calendar of mailbox B.
2. Authenticate the outlook_http adapter as user A.
3. Configure the calendar ID from mailbox B.
4. Run CalendarSync for a timeframe that contains events in B.

Observed in a real deployment:

• CalendarSync requested /me/calendars/{B-calendar-id}/CalendarView.
• The source adapter reported zero loaded events and the run completed successfully.
• A direct Graph request using the same delegated principal and timeframe against /users/{B-UPN}/calendars/{B-calendar-id}/calendarView returned the expected events.

No tokens, calendar IDs, or mailbox identities are included here.

Expected behavior

Allow an Outlook adapter to optionally address an explicit mailbox/user while preserving /me as the default for existing configurations.

For example:

source:
  adapter:
    type: "outlook_http"
    calendar: "[calendar-id]"
    config:
      user: "shared-mailbox@example.com"
    oAuth:
      clientId: "[client-id]"
      tenantId: "[tenant-id]"

Suggested URL behavior:

• no config.user: /me/calendars/{calendarID}/...
• config.user set: /users/{url-escaped-user}/calendars/{calendarID}/...

The value could accept either a user principal name or an Entra object ID.

Implementation scope

A small backward-compatible change should be sufficient:

1. Parse an optional Outlook user/mailbox adapter config value.
2. Centralize construction of the Graph calendar base path.
3. Use that path consistently in ListEvents, CreateEvent, UpdateEvent, and DeleteEvent.
4. Keep the current /me behavior unchanged when the option is absent.
5. Add HTTP tests for both /me and /users/{id} paths across CRUD operations.
6. Ensure the calendar/auth identity used for metadata hashing or storage does not collide across explicitly configured mailboxes, without changing hashes for existing /me configurations.
7. Document the required Microsoft Graph delegated permissions for shared/delegated calendars (Calendars.Read.Shared or Calendars.ReadWrite.Shared) and the corresponding mailbox delegation. Application permissions could remain out of scope for the initial patch.

Microsoft documents direct access to a shared/delegated owner's mailbox using the owner's ID or UPN here:

https://learn.microsoft.com/en-us/graph/outlook-get-shared-events-calendars

Relation to existing issue

This is related to #199, but narrower: it does not require multiple source adapters in one process or service-account support. It only adds an explicit Microsoft Graph mailbox context to one Outlook adapter instance.

If this direction is acceptable, I am willing to prepare a focused PR with tests and documentation.

[frittentheke]

Hey @kai-osthoff! Thanks for your feature idea and the write-up!
This sounds all very reasonable. You may gladly prepare the PR and we shall review it!