Package org.exoplatform.caldav.service

Class CaldavManagedEnrollmentService

java.lang.Object
org.exoplatform.caldav.service.CaldavManagedEnrollmentService
@Service public class CaldavManagedEnrollmentService extends Object
Enrols a user on the CalDAV server managed mode designated, when they log in (EXO-89653): the login-time attachment the board describes.

Three rules, in the order the board states them and with one reordering that changes no outcome: the user already has a CalDAV configuration - whatever server it names - and nothing happens; the user is in a population the administrator excluded and nothing happens; otherwise they are attached to the designated server. The designation is read first here because it is the cheapest read and the one that is null on every instance where managed mode is off.

Having no configuration and having removed one are the same case: a user who disconnects is attached again at their next login, and disconnecting stays useful because whoever connects elsewhere has a configuration, which rule one leaves alone. The outcome itself is not stored - it is a function of (user, designation, exclusions, the user's settings) and a stored outcome would drift the moment an administrator changed one of them.

What is stored is who made the connection: an attachment is marked as made by managed mode (CaldavConnectorUtils.CALDAV_CONNECTED_BY_MANAGED_MODE_KEY), and the mark is checked first. A marked user managed mode no longer governs - they joined an excluded group, or an administrator's change could not disconnect them - is disconnected, then attached again when another server is designated for them.

The attachment is the one-click connect of EXO-90358: the server is probed with the material the provider produces and the connection is recorded only if that passed. A user the designated server does not know is left unattached, and tried again at their next login, rather than recorded as connected to a server that will not answer.

In the background. The login never waits for the remote server: the listener hands the user to a small bounded executor of this service and returns. The load spreads at the rate people arrive, which is why no staggering exists. A full queue drops the attempt with a WARN - the next login retries - rather than blocking the login thread.

Lives beside CaldavManagedModeService rather than inside it: the enrolment needs CaldavRelayService, which needs CaldavServerService, which needs the managed-mode service for its guards - injecting the relay into the managed-mode service would close that cycle.

  • Constructor Details

    • CaldavManagedEnrollmentService

      public CaldavManagedEnrollmentService()

  • Method Details

    • scheduleEnrollment

      public boolean scheduleEnrollment(String username)
      Queues the enrolment of a user who just logged in. Returns at once.
      Parameters:
      username - the eXo login of the user who logged in
      Returns:
      true when the attempt was queued, false when it was dropped

    • enrollOnLogin

      public ManagedEnrollmentOutcome enrollOnLogin(String username)
      Applies the three rules for one user, on the executor's thread.

      @ContainerTransactional because this runs on a bare executor thread: the aspect binds the portal container and a request lifecycle around the call, which the setting reads and the recorded connection need.

      Parameters:
      username - the eXo login of the user who logged in
      Returns:
      what happened, for the tests and the log

    • stop

      @PreDestroy public void stop()