Package org.exoplatform.caldav.client.bluemind

Class BlueMindContainerNaming

java.lang.Object
org.exoplatform.caldav.client.bluemind.BlueMindContainerNaming
public final class BlueMindContainerNaming extends Object
Whose calendar a BlueMind collection is, read from the container uid the server names it by (EXO-90275).

Why the name, and nothing the server answers about the collection. BlueMind lists every calendar a user subscribed to under that user's own home, and says nothing there that would tell it from their own: DAV:owner is built from the uid of the home being listed, not from the container's owner (net.bluemind.dav.server.proto.props.webdav.Owner#fetch), the privilege set grants write whenever the home is the user's (CurrentUserPrivilegeSet#fetch), and the listing walks the user's subscriptions (DavStore#getCalendarDavResource, which reads the real owner only to filter). What does carry the owner is the container uid, which is the collection's last path segment, and which BlueMind mints in three shapes (net.bluemind.calendar.api.ICalendarUids, UserCalendarService):

  • calendar:Default:<user uid> — a user's main calendar;
  • calendar:UserCreated:<user uid>:<random uuid> — a calendar a user created;
  • calendar:<resource uid> — a resource's calendar (ResourceCalendarHook: ICalendarUids.resourceCalendar(resource.uid)).
A uid other than the account's own principal uid names somebody else, and the collection is a subscription: to a person's calendar in the first two shapes, to a resource in the third.

What it does not read. A collection created over CalDAV takes the client's own path segment as its container uid (MkCalendarProtocol: eXo's exo-cal-*, a bare uuid), and a domain calendar an administrator creates gets a bare uuid (QCreateCalendarModelHandler) — none of those shapes names an owner and all of them are left to the other witnesses. A client may still create a collection named calendar:<something> over CalDAV, which BlueMind accepts as it is; the name then points at nobody, which is why a binding is retired only once the owner it points at answers (CaldavSubscriptionRetirementService). The rule is read only on an account of BlueMind's shape (see isBlueMindAccount(java.lang.String, java.lang.String, java.lang.String)). Nor does it ask calendar-user-type (RFC 6638): BlueMind's principal defines no such property (store/path/Principal). A server that names no principal switches the rule off, as it switches the owner comparison off: an owner that cannot be compared is not evidence of a subscription.

The uid comparison ignores case, as CaldavPushService does when it picks the account's own :Default: calendar (EXO-90225).

  • Method Details

    • subscriptionOf

      public static BlueMindContainerNaming.Subscription subscriptionOf(String href, String principal)
      The subscription a listed collection is, when its container uid names somebody other than the account.
      Parameters:
      href - the collection's path, raw or canonical
      principal - the account's own current-user-principal path, may be null or blank when the server named none
      Returns:
      the subscription, or null when the collection is not one of the three shapes, names the account itself, or no principal is known

    • principalOf

      public static String principalOf(String principal, String uid)
      The principal path of the person or resource a subscription names, in the account principal's own collection.

      BlueMind spells every principal <dav root>/principals/__uids__/<uid>/ (CurrentUserPrincipal#fetch), so the owner's is the account's with the last segment replaced. Built from the account's answer rather than from a constant, so a server mounted under another root keeps it.

      Parameters:
      principal - the account's own principal path, not blank
      uid - the owner's uid, as subscriptionOf(java.lang.String, java.lang.String) returned it
      Returns:
      the owner's principal path, slash-terminated like the account's

    • userUidOf

      public static String userUidOf(String principal)
      The directory entry uid a BlueMind user principal names: the last segment of <dav root>/principals/__uids__/<uid>/ (CurrentUserPrincipal#fetch; ResType.PRINCIPAL).

      The uid is what BlueMind's REST API addresses a user by — the subject of an access entry, of a subscription edit — so it is the one thing a recorded principal has to yield for eXo to act on that user's behalf (EXO-90253, EXO-90277). A principal of another shape yields nothing: acting on a guessed uid is worse than not acting.

      Parameters:
      principal - a principal path, any spelling, may be null
      Returns:
      the uid, or null when the path is not a BlueMind user principal