Package org.exoplatform.agenda.plugin

Interface RemoteEventCopyPlugin

public interface RemoteEventCopyPlugin
Answers, for the add-on that writes meeting copies into a user's connected calendar account, whether it is going to write one — asked by agenda before it decides anything that depends on the answer.

Why agenda asks instead of predicting (EXO-90247)

Agenda has one decision that turns on this: whether the invitation mail carries an event.ics file. The file exists so that a recipient whose calendar eXo cannot reach still gets the meeting; it is left out for a recipient who will hold a synced copy, because the two documents carry different UIDs and no client can tell they are one meeting.

Agenda used to answer that by reading the recipient's own settings, which is a guess at a decision another add-on owns — and the two drifted, in both directions at once. The add-on's server-side seeding pass writes a copy for a user whose automaticPushEvents is off, where agenda predicted none and attached the file: the meeting twice. And when the add-on gained a reason of its own to decline a copy, agenda knew nothing of it, predicted a copy, and left the file out: the meeting nowhere, which is how the first attempt at EXO-90247 turned a duplicate into total silence for the invitee it was meant to help.

So the answer moves to the only party that can give it — the one that will do the writing. Agenda keeps its settings-derived guess for the deployment where no add-on is installed to be asked, and nowhere else.

The contract, and which way to err

The two mistakes do not cost the same. Answering true when no copy is written takes the file away from somebody who then receives the meeting through nothing at all — a missing invitation, with nothing in their calendar or their mail to suggest why. Answering false when a copy is written gives them the meeting twice, which is visible and which they can delete. So an implementation that cannot establish its answer — a setting it cannot read, a server it cannot reach, a failure of any kind — answers false, never true.

It is a prediction and cannot be anything else: the invitation is dispatched synchronously inside event creation, while a copy is written by a background pass minutes later. What the implementation is being asked is "will you", not "did you".

How it is registered

As a Spring @Service bean, non-final, in the contributing add-on's own context — agenda collects every bean of this type at the moment it asks, so an add-on whose WAR boots after agenda's is found just the same, and a deployment without the add-on simply has none.

  • Method Summary

    Modifier and Type
    Method
    Description
    boolean
    writesCopyOf(Event event, long recipientIdentityId)
    Whether this add-on will write its own copy of this meeting into that recipient's connected calendar account.

  • Method Details

    • writesCopyOf

      boolean writesCopyOf(Event event, long recipientIdentityId)
      Whether this add-on will write its own copy of this meeting into that recipient's connected calendar account.

      Answers false rather than throwing on anything it cannot establish; see the asymmetry stated on this interface.

      Parameters:
      event - the meeting, as agenda holds it — never null
      recipientIdentityId - organization identity id of the recipient, which is 0 for a guest, who has no account and therefore never a copy
      Returns:
      true only when a copy of this meeting is going to be written for that recipient