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: the user is in a population the administrator excluded, or nothing is designated, and nothing happens; the user already has a CalDAV configuration on the designated server and nothing happens; otherwise they are put on the designated server - attached when they have no configuration, switched when their account is on another server (EXO-90836). The designation is read first because it is the cheapest read and the one that is null on every instance where managed mode is off.

A switch probes the designated server before it changes anything: a refusal leaves the user's account as it was, and the next login tries again. A user managed mode governs cannot disconnect, connect with typed credentials or connect another server themselves (CaldavManagedModeService.checkUserMayChangeConnection(String, Long)), so the server the instance designates is the only one they end up on. 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 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()