Package org.exoplatform.caldav.client.bluemind

Class BlueMindSubscriptionClient

java.lang.Object
org.exoplatform.caldav.client.bluemind.BlueMindSubscriptionClient
@Component public class BlueMindSubscriptionClient extends Object
Edits a colleague's own BlueMind subscriptions through BlueMind's REST API, as that colleague (EXO-90277).

Why a subscription at all. A CS:share writes an access entry and nothing else (SharingProtocol.java); BlueMind's DAV home lists subscriptions, not readable containers (DavStore.java, getCalendarDavResource), and so does its webmail, whose "Add" modal subscribes a readable-but-unsubscribed container with offlineSync=true (SubscribeOtherContainersModal.vue). So a calendar shared from eXo is invisible to the colleague — in eXo and in BlueMind — until somebody subscribes them, and this client does what their "Add" click would.

The call. POST /api/users/{domainUid}/subscriptions/{subject}/_subscribe with a JSON array of {containerUid, offlineSync, automount} (parent/user/net.bluemind.user.api/.../IUserSubscription.java, ContainerSubscription.java); the reverse is _unsubscribe with an array of container uids. The service checks ROLE_MANAGE_USER_SUBSCRIPTIONS or ROLE_SELF on the subject in the container's domain (UserSubscriptionService.java) — the subject's own session, same domain — and no access check: subscribing is a per-user display preference, readable or not. A subscription that already exists is updated, not refused, so the call is idempotent. The answer is a 200 with an empty body; a fault is {errorCode, errorType, message} — 403 for PERMISSION_DENIED, and for an unknown container NOT_FOUND (subscriptionToContainer), which ResponseBuilder.replyServerFault sends as a 500 at BlueMind master and which this client also accepts as a 404, since no capture has yet settled which of the two a live server sends; both are the same absence here.

Whose session, and the one check that guards it. The session is opened with the colleague's stored credentials — the endpoint is minted for their eXo login — because only they may edit their subscriptions. The {domainUid} in the path is not stored anywhere in eXo; it comes from the login answer, as does authUser.uid, and the client refuses before any POST when that uid is not the one it was asked to edit (BlueMindSubjectMismatchException): a principal recorded from a stale discovery, or a colleague reconnected as somebody else, must never make eXo edit another account with a password it holds. The session is still closed by BlueMindRestSession.call(org.exoplatform.caldav.client.CalDavEndpoint, java.util.function.Function<org.exoplatform.caldav.client.bluemind.BlueMindRestSession.Session, T>).

Same server, the colleague's credentials from storage, one session per job, nothing secret in a message: BlueMindRestSession's rules, shared with every other REST conversation this add-on holds with BlueMind.

  • Field Details

    • OFFLINE_SYNC

      public static final boolean OFFLINE_SYNC
      Whether the subscribed calendar also synchronises to the colleague's devices: BlueMind's own webmail default, and the PO's choice — the calendar reaches their phone as a hand subscription would.
      See Also:

    • AUTOMOUNT

      public static final boolean AUTOMOUNT
      Whether the subscription is mounted in the colleague's views at once.
      See Also:

  • Constructor Details

    • BlueMindSubscriptionClient

      @Autowired public BlueMindSubscriptionClient(BlueMindRestSession session)
      The client Spring builds, over the shared session.
      Parameters:
      session - the REST session every BlueMind conversation shares

  • Method Details