Package org.exoplatform.caldav.service

Class CaldavCalendarOwnerService

java.lang.Object
org.exoplatform.caldav.service.CaldavCalendarOwnerService
@Component public class CaldavCalendarOwnerService extends Object
Names the owner of a calendar shared with the user, from whichever witness said it was shared (EXO-90237).

The calendar list already knows a collection is somebody else's (CaldavOutboundService.ownershipOf(long, java.lang.String, java.util.List<org.exoplatform.caldav.model.CalendarSync>, org.exoplatform.caldav.client.CalendarCollection)); what it could not say was whose, so a colleague's calendar sat under a section named after the server with nothing to tell the user it was shared, let alone by whom. This answers the second question from the first's own evidence, and from nothing else:

  • A colleague's eXo calendar was recognised by the pair this deployment holds for it, and that pair names its user. The owner is that user, resolved through the identity registry to a login and a full name — which is what agenda needs to show the person rather than a lock. On BlueMind this is the only owner there is to name: the server reports the viewer as owner of a calendar they merely subscribed to, so its word would name the wrong person.
  • A share the server reported names an owner principal. When exactly one eXo user of this deployment is connected to that server as that principal — the identity each connection's discovery records (EXO-90243), and every user synchronising with that server has been recorded, so that "exactly one" is not merely "one so far" — the owner is that user, named as a colleague is. Otherwise — nobody connected as it, several eXo users on that one login, the viewer themself, or a server whose users are not all recorded yet — the owner is a name alone: the principal's DAV:displayname, read with one PROPFIND of depth 0, or when the server answers none, refuses, or cannot be reached, the decoded last segment of the principal path — the very path the server returned to the viewer, so nothing is shown that the viewer was not already told.
  • The user's own calendars, and anything else, name nobody.

Naming the owner to the viewer is acceptable because the viewer already holds read access the owner granted, on the server or in eXo; mapping the principal to a colleague shows the viewer the eXo person behind a login the server has already named to them, and only when the mapping is unambiguous. What this class never does is fail or slow a listing over an owner: the identity lookups are local, the PROPFIND is bounded by the client's own timeouts, both are memoised per principal within one listing, and every failure degrades to a lesser name or to none.

  • Constructor Details

    • CaldavCalendarOwnerService

      @Autowired public CaldavCalendarOwnerService(CaldavOutboundService caldavOutboundService, org.exoplatform.social.core.manager.IdentityManager identityManager, CalDavClient calDavClient, CaldavConnectionIdentityService caldavConnectionIdentityService)
      Parameters:
      caldavOutboundService - the one place that knows which user's pair stands behind an eXo-minted collection
      identityManager - the registry that turns that user into a login and a full name
      calDavClient - the client that asks a principal what it calls itself
      caldavConnectionIdentityService - the record of which eXo users are connected as which principal

  • Method Details

    • ownerOf

      public CalendarOwner ownerOf(long viewerIdentityId, long serverId, CalDavEndpoint endpoint, String principal, CollectionOwnership ownership, CalendarCollection collection, org.exoplatform.caldav.service.CalendarOwnerMemo memo)
      Who a listed collection belongs to, given whose the list already found it to be.
      Parameters:
      viewerIdentityId - the eXo user the list is for, who is never named as the owner of a calendar shared with them
      serverId - the declared server registration the account is on
      endpoint - the account's endpoint, which a principal is asked through — never another authority
      principal - the account's own current-user-principal, as the discovery walk answered it; null when the server named none. What a server-named owner is compared against, so that a share by privilege alone whose owner is the user themself names nobody rather than the user
      ownership - whose the collection is, as CaldavOutboundService.ownershipOf(long, java.lang.String, java.util.List<org.exoplatform.caldav.model.CalendarSync>, org.exoplatform.caldav.client.CalendarCollection) answered
      collection - the listed collection
      memo - what this listing already found out about owners: read and written here, so that two shares of one colleague cost one lookup and at most one PROPFIND, not two, a principal that could not be asked is not asked again, and a server's count of unrecorded users is asked once, whatever the number of colleagues' shares
      Returns:
      the owner, CalendarOwner.NONE for the user's own and for a share whose owner cannot be named