Package org.exoplatform.caldav.service

Class CaldavInboundService

java.lang.Object
org.exoplatform.caldav.service.CaldavInboundService
@Service public class CaldavInboundService extends Object
Brings the events of a materialised collection into the eXo calendar standing for it.

This is the half that makes a materialised calendar more than a shell. Until it runs, the user sees a calendar with the right name and no events in it, which is why the browser overlay cannot be retired before this.

  • Constructor Details

    • CaldavInboundService

      public CaldavInboundService()

  • Method Details

    • importInto

      public int importInto(long userIdentityId, String username, org.exoplatform.caldav.model.CalendarSync pair, org.exoplatform.agenda.model.Calendar calendar, Instant from, Instant to)
      Imports the objects of one bound collection over a window.

      A window rather than the whole collection: a calendar with ten years of history behind it would otherwise cost a full download on a page load. The window is the caller's to choose, and widening it is a decision about cost, not about correctness.

      Parameters:
      userIdentityId - identity of the user
      username - their eXo login, which the credentials provider maps to their account on the server
      pair - the binding whose collection is read
      calendar - the eXo calendar standing for it
      from - beginning of the window
      to - end of the window
      Returns:
      how many events were created or updated

    • syncContents

      public CaldavInboundService.VanishedCleanup syncContents(long userIdentityId, String username, org.exoplatform.caldav.model.CalendarSync pair, org.exoplatform.agenda.model.Calendar calendar, Instant from, Instant to, boolean fullRead)
      Brings a collection's contents into eXo and removes what left it, in one conversation with the account.

      The pass used to ask two separate questions. What changed was answered by re-reading the whole window — 426 days cut into 30-day slices, so fifteen REPORTs each carrying the full iCalendar of everything in its slice. Changing one event's title asked a real server to re-send a year, fifteen times over, and the user waited for it. What vanished was answered separately.

      A sync token answers both at once, and cheaply: RFC 6578 returns the handful of objects that changed and the handful that were removed. The changed ones are then fetched by path — one multiget carrying one event rather than fifteen REPORTs carrying a year.

      One report, never two. The two halves must come from the same call: a report consumes the token it was given and hands back a new one, so two calls sharing a token would let whichever ran second miss everything the first had already taken. That is why importing and reconciling live in one method rather than being called in sequence.

      The window still has to be read in full sometimes, and that is what fullRead is for. A token says what changed; it says nothing about days sliding into range as time passes. An event a year out is untouched by anyone and reported by nothing, and it still has to appear when the window reaches it — so the caller asks for a full read when the window has moved, which is once a day.

      Parameters:
      userIdentityId - identity of the user
      username - their eXo login, which the credentials provider maps to their account on the server
      pair - the binding being read
      calendar - the eXo calendar it fills
      from - start of the window, for a full read
      to - end of the window, for a full read
      fullRead - true to re-read the whole window rather than ask what changed — a binding with no token, or one whose window has moved
      Returns:
      what the reconciliation removed and what it could not

    • removeVanishedObjects

      public CaldavInboundService.VanishedCleanup removeVanishedObjects(long userIdentityId, String username, org.exoplatform.caldav.model.CalendarSync pair)
      Removes the eXo events whose objects are no longer on the account.

      The other half of reading a calendar back in. An event created or edited on the user's phone reaches eXo; an event deleted there did not, because an object that is gone is simply absent from what the server returns, and absence was never looked for. The calendar the user is looking at on their phone and the one eXo shows them drift apart, and nothing says so.

      The listing is deliberately a full PROPFIND of the collection rather than the windowed query the import uses. The import walks a time window in slices, so an object it did not return may simply lie outside the window — concluding "deleted" from that would destroy every event the user has outside the period eXo happens to read.

      Two further limits, both because this deletes the user's data:

      • only events eXo holds a mapping for are ever removed. An event authored in eXo that never reached the account has no mapping and is not this method's business;
      • a listing that could not be made removes nothing. An unreachable server is not a statement that everything was deleted, and treating it as one would empty the user's calendar the moment their network dropped.
      Parameters:
      userIdentityId - identity of the user, whose ACL the deletion runs under
      username - their eXo login, which the credentials provider maps to their account on the server
      pair - the binding whose collection is reconciled
      Returns:
      what was removed and what could not be

    • removeVanishedObjects

      public CaldavInboundService.VanishedCleanup removeVanishedObjects(long userIdentityId, String username, org.exoplatform.caldav.model.CalendarSync pair, String calendarName)
      The same, told which calendar it is working on so its warnings can name it.

      A collection href is exo-cal-<syncUid>, and nothing a user or an administrator can reach maps that back to a calendar — the agenda REST does not expose syncUid at all. A warning naming only the href therefore cannot be acted on by the person reading it, which is how one failing collection went unexplained for a whole morning.

      Parameters:
      userIdentityId - identity of the user
      username - their eXo login, which the credentials provider maps to their account on the server
      pair - the binding whose collection is reconciled
      calendarName - the eXo calendar's name, for the log only, may be null
      Returns:
      what was removed and what could not be