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): what the collection advertises, CalDavClient.capabilities(org.exoplatform.caldav.client.CalDavEndpoint, java.lang.String); a contributed CalendarShareChannel may claim the collection from where it 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.

Nested Class Summary

Nested classes/interfaces inherited from class java.lang.Enum

Enum.EnumDesc<E extends Enum<E>>

Enum Constant Summary

Enum Constants

Enum Constant	Description
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.
CALENDARSERVER_SHARE	Apple sharing (POST of a CS:share body, or the resource-sharing draft) on a server that is not recognised as BlueMind.
NONE	No granting mechanism eXo knows of: Google, or a server without RFC 3744.
WEBDAV_ACL	RFC 3744 §8.1: the owner writes the collection's whole access control list with the ACL method.

Method Summary

Modifier and Type	Method	Description
boolean	isOffered()	Whether eXo offers granting through this mechanism.
static SharingMechanism	of(DavOptions options)	The mechanism a collection's advertised DAV classes and allowed methods select, read from those alone.
static SharingMechanism	valueOf(String name)	Returns the enum constant of this class with the specified name.
static SharingMechanism[]	values()	Returns an array containing the constants of this enum class, in the order they are declared.

Methods inherited from class java.lang.Enum

clone, compareTo, describeConstable, equals, finalize, getDeclaringClass, hashCode, name, ordinal, toString, valueOf

Methods inherited from class java.lang.Object

getClass, notify, notifyAll, wait, wait, wait

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.

Selected and carried by a contributed share channel (org.exoplatform.caldav.plugin.CalendarShareChannel), never by the host itself (EXO-90730): without the BlueMind channel installed a BlueMind collection selects CALENDARSERVER_SHARE, which is not offered. The constant stays because the name is in logs and REST answers; a second server-specific mechanism would open it to plugin-declared names.

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