Package org.exoplatform.caldav.client

Enum Class SharingMechanism

java.lang.Object
java.lang.Enum<SharingMechanism>
org.exoplatform.caldav.client.SharingMechanism
All Implemented Interfaces:
Serializable, Comparable<SharingMechanism>, Constable
public enum SharingMechanism extends Enum<SharingMechanism>
How a calendar server lets an owner grant somebody else access to a collection, and whether eXo offers it there (EXO-90253).

The catalogue of granting mechanisms, in code: an entry is a protocol and a verdict on it, and which entry a server gets is selected from what the server says about itself (of(DavOptions, String): what the collection advertises, CalDavClient.capabilities(org.exoplatform.caldav.client.CalDavEndpoint, java.lang.String), and, for BlueMind, where the collection lives), not ticked by an administrator nor frozen on a registration row. Granting is not a CalDAV feature — no RFC defines calendar sharing — so the two servers this add-on targets have nothing in common here: Stalwart takes RFC 3744's ACL method and nothing else, BlueMind takes Apple's POST CS:share (design note 52695 B.8.2, review 52697).

Offered only where every change can be confirmed. An entry is offered when eXo can read back, after each grant and revoke, whether the server applied it, and reports "not applied" otherwise. How it is confirmed differs per server. On Stalwart, the ACL is read over DAV, and a grant was also seen to reach the sharee live (note 52696). On BlueMind, the owner cannot read the ACL over DAV (note 52697, live results of 2026-09-13), so the container's access list is read through BlueMind's REST API. BLUEMIND_SHARE is offered on BlueMind's source code and on that read-back. The live capture of a BlueMind grant is still pending: the BlueMind section of the delivery's live test.

  • Enum Constant Details

    • WEBDAV_ACL

      public static final SharingMechanism WEBDAV_ACL
      RFC 3744 §8.1: the owner writes the collection's whole access control list with the ACL method. Verified on Stalwart 0.16 on 2026-09-13: a read grant from Alice to Bob answered 200, and Alice's calendar was then listed in Bob's own home, owned by Alice and read-only for him (note 52696).

    • CALENDARSERVER_SHARE

      public static final SharingMechanism CALENDARSERVER_SHARE
      Apple sharing (POST of a CS:share body, or the resource-sharing draft) on a server that is not recognised as BlueMind. Not offered: nothing tells eXo how such a server resolves a sharee or how a change could be read back. A collection in BlueMind's layout is BLUEMIND_SHARE instead.

    • BLUEMIND_SHARE

      public static final SharingMechanism BLUEMIND_SHARE
      Apple sharing as BlueMind's DAV server implements it (BlueMind source, plugins/net.bluemind.dav.server/.../proto/sharing/SharingProtocol.java): a POST of CS:share on a calendar collection names the sharee by e-mail, and the server rewrites the container's access list through its own container management. Offered, with two things eXo does around it because the protocol cannot: the server answers 200 whatever happened, so every change is confirmed by reading the container's access list back through BlueMind's REST API; and the server rewrites or removes every entry of the sharee, so a sharee holding anything but plain reading is refused rather than downgraded.

    • NONE

      public static final SharingMechanism NONE
      No granting mechanism eXo knows of: Google, or a server without RFC 3744.

  • Method Details

    • values

      public static SharingMechanism[] values()
      Returns an array containing the constants of this enum class, in the order they are declared.
      Returns:
      an array containing the constants of this enum class, in the order they are declared

    • valueOf

      public static SharingMechanism valueOf(String name)
      Returns the enum constant of this class with the specified name. The string must match exactly an identifier used to declare an enum constant in this class. (Extraneous whitespace characters are not permitted.)
      Parameters:
      name - the name of the enum constant to be returned.
      Returns:
      the enum constant with the specified name
      Throws:
      IllegalArgumentException - if this enum class has no constant with the specified name
      NullPointerException - if the argument is null

    • isOffered

      public boolean isOffered()
      Whether eXo offers granting through this mechanism.
      Returns:
      true for a mechanism whose every change eXo can confirm by reading it back

    • of

      public static SharingMechanism of(DavOptions options)
      The mechanism a collection's advertised DAV classes and allowed methods select, read from those alone.

      Read in this order, and the order is the point:

      1. A vendor sharing protocol advertised ( calendarserver-sharing, or draft-pot's resource-sharing) selects CALENDARSERVER_SHARE, whatever else the server says. On such a server the ACL is the storage its own sharing layer manages, and a grant written beside that layer is not what its users or its UI see. BlueMind is the case that makes this rule first: its captured DAV header advertises access-control as well as calendarserver-sharing (bluemind-principal.captured.xml), so a rule on RFC 3744 alone would offer it.
      2. RFC 3744 access control advertised, the ACL method allowed, and no calendar-proxy delegation layered on top selects WEBDAV_ACL. Stalwart answers exactly this (design A.5, live OPTIONS). The delegation exclusion keeps out servers whose proxy groups are mapped onto the same ACL (SOGo).
      3. Anything else is NONE: Google advertises no access control at all.
      A server outside the ones characterised that answers the second shape is offered too, with two guards the service applies to every grant: an ACL it cannot parse entirely is never written back, and a grant not visible when the ACL is read again is reported as not applied.
      Parameters:
      options - what the collection answered, null when nothing was asked
      Returns:
      the mechanism, never null

    • of

      public static SharingMechanism of(DavOptions options, String collectionHref)
      The mechanism what a collection advertises (CalDavClient.capabilities(org.exoplatform.caldav.client.CalDavEndpoint, java.lang.String)) selects, given where the collection lives.

      Apple sharing is offered on one server only, and BlueMind is recognised by two independent facts that must both hold: it advertises calendarserver-sharing in the DAV header of its PROPFIND answers (PropFindProtocol.java:125, captured in bluemind-principal.captured.xml; where its OPTIONS is answered bare in front of its DAV server, as on the deployments observed, CalDavClient.capabilities(org.exoplatform.caldav.client.CalDavEndpoint, java.lang.String) reads them from a PROPFIND), and the collection has the path BlueMind's DAV server gives every calendar, /dav/calendars/__uids__/<owner uid>/<container uid>/ (ResType.VSTUFF_CONTAINER). Apple's CalendarServer uses the same __uids__ layout without the /dav root, and Nextcloud and iCloud use other paths; those stay not offered. The service confirms the recognition before any change: BlueMind's REST API must accept the owner's login, which no other server answers.

      Parameters:
      options - what the collection answered, null when nothing was asked
      collectionHref - the collection's path, may be null
      Returns:
      the mechanism, never null

    • isBlueMindCollection

      public static boolean isBlueMindCollection(String collectionHref)
      Whether a path is a calendar collection as BlueMind's DAV server names one.
      Parameters:
      collectionHref - the collection's path, may be null
      Returns:
      true for /dav/calendars/__uids__/<uid>/<container>/