All Classes and Interfaces
Class
Description
One access control entry of a collection's
DAV:acl, as RFC 3744
§5.5 defines it: who it applies to, whether it grants or denies, which
privileges, and whether the server lets it be changed (EXO-90253).Whom an entry applies to: one of the six forms RFC 3744 §5.5.1 allows.
The forms of
DAV:principal.What the server itself says about who owns each calendar an account sees
— the fourth witness
CaldavOutboundService#ownershipOf hears
(EXO-90347), asked at most once per account per pass.The server's word on one calendar, and the owner it named.
What the server said about one calendar.
What the server answered to an
ACL request (EXO-90253): a claim,
never a fact.Turns an agenda event into what the ICS engine takes.
What the two agenda-modification listeners share: unwrapping the broadcast,
resolving the propagation service, and refusing to run outside a container.
Reads the access control list of a BlueMind calendar through BlueMind's own
REST API — the one place its sharing state can be read (EXO-90253).
One entry of a BlueMind container's access list.
Writes and removes calendar objects through BlueMind's own calendar REST
API — the door whose every change carries
sendNotification=false
(EXO-90307).What one import task reported when it ended.
How the poll loop waits between two status reads — a seam, so a test can
drive the deadline without spending the time.
Whose each calendar in a BlueMind account's view is, as BlueMind's own
subscription listing reports it (EXO-90347).
Whose calendar a BlueMind collection is, read from the container uid the
server names it by (EXO-90275).
A subscription the naming revealed: whose uid the container carries,
and whether that uid is a resource's.
The BlueMind door: every write is an ICS import, every removal a REST
delete with notifications off, and the version eXo records afterwards is
the one the collection's own listing publishes (EXO-90307).
What a login answered and a session carries: the address it answered at,
the key, and who BlueMind says the session belongs to.
The one way eXo talks to BlueMind's own REST API: a session opened with the
account's stored login and password, kept per account for a short while
(see
call), every call carrying the key it answered.An answer: status and body text.
BlueMind as a server flavour: recognised by its registration's name, it
may write through
WriteChannel.BLUEMIND_IMPORT, and it keeps a REST
session per account (EXO-90397) that eXo drops when the account or the
registration changes.The BlueMind REST session each account currently holds, kept in this node's
own memory for a few minutes so that a burst of reads costs one login
rather than one login per read (EXO-90397).
The account a session belongs to.
Drops the BlueMind REST session an account holds when eXo itself changes
what that account is (EXO-90397).
Sharing a BlueMind calendar with a colleague (EXO-90253, EXO-90277,
EXO-90378): Apple's
POST CS:share over DAV, every change confirmed
by reading the container's access list back through BlueMind's REST API
(BlueMindAclClient), and the colleague subscribed to the calendar
once a grant is confirmed.The session BlueMind opened belongs to somebody other than the account eXo
meant to edit, so nothing was sent (EXO-90277).
BlueMind's subscriptions as a channel: its container naming
(
BlueMindContainerNaming) tells a subscription from the account's
own calendar, and its REST subscription API
(BlueMindSubscriptionClient) subscribes a colleague to a calendar
shared with them (EXO-90275, EXO-90277, EXO-90347).Edits a colleague's own BlueMind subscriptions through BlueMind's REST API,
as that colleague (EXO-90277).
The edits one open session, checked to be the colleague's own, can make.
Contributes BlueMind's import door for
WriteChannel.BLUEMIND_IMPORT.Reads the one field a user may answer through their own calendar — their own
PARTSTAT on a copy eXo pushed — and records it in agenda (EXO-89681).
What one adoption pass over one object did.
The server refused the credentials.
Names the owner of a calendar shared with the user, from whichever witness
said it was shared (EXO-90237).
Carries a calendar share agenda recorded onto the owner's CalDAV server
(EXO-90357): the colleague's principal is granted read access to the
collection the calendar is bound to, through
CaldavCalendarShareService
and every check it makes, and the grant is taken away when agenda revokes
the share.Shares a user's own eXo calendar, read-only, with colleagues connected to
the same CalDAV server, by changing who may read the collection that
calendar is bound to — through the server's own granting mechanism, confirmed by
reading the access list back (EXO-90253).
A calendar's collection on the caller's server and the shares read from
it, both from one resolution of the calendar (EXO-90385).
A calendar's collection on the caller's server.
Persistence access to the calendar pairs.
The binding between one eXo calendar and one remote collection, for one user
on one declared server.
The CalDAV protocol, and nothing else: it fetches, it does not decide.
Persistence access to who each connected eXo user is on their CalDAV server
(EXO-90243).
Who one eXo user is on the CalDAV server their account is connected to: the
current-user-principal the server named when the account was last
discovered (EXO-90243).Who each connected eXo user is on their CalDAV server, and which eXo users
are connected as a given principal (EXO-90243).
Reads and writes who each connected eXo user is on their CalDAV server
(EXO-90243).
Whether a user has said yes to meeting copies at all, said once.
Which eXo events a calendar copy may stand for, said once.
The CalDAV side of the shared credentials contract: the one place that knows
how this connector addresses a provider, so that the two questions a caller
ever asks — which account would the material address and what
header do I send — are answered from a single context.
Deleting a personal calendar, on both sides.
How many accounts an administrator's change would disconnect, answered before the
change is applied so that the screen can say so.
Where a CalDAV conversation is allowed to go: the scheme and authority of
one administrator-declared server, plus the account's base collection path
on it.
Carries what happens to a meeting in eXo out to the calendars of the people
it concerns: a creation to everyone invited, an edit or a cancellation to
every copy that already exists, a deletion to every copy that has to go.
The one failure the CalDAV client throws for protocol and transport
trouble: the server unreachable, an answer outside the accepted statuses
of the verb, a body that is not DAV XML, or a target this client refuses
to address.
The server accepted the credentials and refused the write anyway: a 403 on
a PUT or a DELETE, which is how a CalDAV server says "this resource is not
yours to change".
Name resolution as a seam.
Admits the DAV verbs through this webapp's Spring Security firewall.
Brings the events of a materialised collection into the eXo calendar
standing for it.
What one reconciliation managed.
Hands the disconnections an administrator's change causes to
CaldavManagedDisconnectionService, which runs them in the background.Disconnects the users an administrator's change leaves on a CalDAV server that is no
longer theirs, and counts them beforehand for the warning the
administration screen shows.
Enrols a user on the CalDAV server managed mode designated, when they log in
(EXO-89653): the login-time attachment the board describes.
Hands each login to the managed-mode enrolment (EXO-89653).
Published when an administrator changes the CalDAV managed mode - the designated
server, its exclusions, or managed mode switched off.
What the administration drawer sends to point the whole instance at one
declared server: the server, and the groups the choice must not reach.
Whether the instance chooses the CalDAV server for its users instead of
letting each of them connect an account of their own.
Reads the owner's answers off the copies in a collection nothing else
reads (EXO-89814).
Moves the copies already on the server when the destination changes.
The last pass over each user's copies, kept so somebody can look.
Checks that the copies eXo pushed are still there, and still what eXo wrote
— and reads back the one field the user is allowed to change on them.
The server says the thing a call addressed does not exist.
Persistence access to the object mappings.
One event's identity across the two sides: the eXo event, the iCalendar
object it corresponds to, and what was last written or read.
The CalDAV door: every write is the
CalDavClient method of the same
name, with the same headers, the same body and the same answer.Gives each of a user's eXo personal calendars a collection of its own on the
remote server.
The thread outward copies are written from, and the accounts whose outward
work is under way.
Puts the meetings a user has not answered yet into their own calendar, with
their honest
PARTSTAT=NEEDS-ACTION (EXO-89681).Persistence access to the writes eXo owes but has not made.
One write eXo owes a calendar copy: recorded before it is attempted, deleted
when it lands, retried by the sweep until it does or until it has been
refused often enough to stop.
Maps the writes eXo owes a calendar copy between their JPA entity and the
service-layer DTO.
The subscription changes eXo owes colleagues' BlueMind accounts
(EXO-90277).
One subscription change eXo owes a colleague's BlueMind account and has not
managed to make (EXO-90277): the table
CALDAV_PENDING_SUBSCRIPTION.Maps the subscription changes eXo owes colleagues' BlueMind accounts
between their JPA entity and the service-layer DTO (EXO-90277).
Exposes the CalDAV connector's own stored personal credentials to the generic
PersonalCredentialsProvider.A push that could not be carried out, carrying the machine-readable code the
browser already knows how to turn into a message the user can act on.
The write endpoints the browser calls now that it no longer builds
iCalendar itself.
Writes eXo's space events into the user's remote calendar, server-side.
What became of one attempt to write an answer onto one copy.
The read endpoints the page calls instead of downloading and parsing every
iCalendar object itself.
Reads the connected account's calendars server-side, so the page receives
mapped events instead of downloading and parsing every iCalendar object in
the main thread.
HTTP face of the CalDAV relay:
/caldav/rest/dav/{serverId}/**
forwards DAV requests of the authenticated user to the declared server the
id names, and /caldav/rest/connection/verify probes typed
credentials at connect time.The server-side DAV relay: the browser addresses declared CalDAV servers
through
/caldav/rest/dav/{serverId}/** and this service forwards
each request to the one host the registry row names, injecting the
connected user's stored credentials.Tells agenda whether this add-on is going to write a user's copy of a meeting
into their connected calendar account (EXO-90247).
Persistence access to the CalDAV server registrations.
A CalDAV server declared by an administrator.
Asks the server whose each calendar in an account's view is — once per
account per pass at most, and mostly from a cache (EXO-90347).
The owner of every calendar an account sees, as BlueMind's subscription
listing reports it, kept across passes (EXO-90347).
The account a listing belongs to: the declared server and the eXo user
whose stored credentials open the session.
Published when an administrator moves a CalDAV server to another credentials provider.
What each CalDAV server has been seen doing, and what its administrator has
excused it for.
REST access to the CalDAV server registry.
The registry of CalDAV servers a deployment offers its users: what an
administrator declares in the third section of the agenda administration
page.
Maps CalDAV server registrations between their JPA entity and the
credential-free
CaldavServer DTO.Checks the address of a CalDAV server BEFORE the platform is made to connect
to it.
A share of a calendar that could not be read, granted or removed for a
reason that is neither the caller's request nor their rights: the account,
the server's capability, or the server's own answer (EXO-90253).
Sharing a user's own eXo calendar, read-only, with colleagues connected to
the same CalDAV server (EXO-90253).
Makes a calendar shared from eXo on BlueMind appear to the colleague it was
shared with, by subscribing their BlueMind account to it as they would
themselves — and removes that subscription when the share is revoked
(EXO-90277).
The calendar server authenticated a session as somebody other than the
account eXo asked for, and nothing was sent in it.
Stops the harm a calendar the sweep materialised from a mere subscription
does, before the server's naming was read (EXO-90275).
What retiring one binding came to.
Keeps a user's eXo calendars and their remote collections in step, in both
directions.
The pieces of outward work a pass may do once the calendars themselves are
in step — each named, and each governed on its own.
Maps calendar pairs and their object mappings between their JPA entities and
the service-layer DTOs, and is the single place hrefs are made canonical.
Keeps connected CalDAV accounts fresh without waiting for their owner.
How often and how widely the engine synchronises, and who gets to say.
The conversation never reached the calendar server: the transport failed
outright, or a gateway standing in front of the server answered that it
could not reach it either (502, 503, 504).
One calendar collection as a PROPFIND listed it: everything the sync
engine binds a pair on, and nothing it does not need.
Pushes a calendar to the user's CalDAV server as soon as they create it.
What one discovery walk answers: who the authenticated user is on the
server, and where that user's calendars live.
One calendar object (an .ics resource) as the server answered it.
The door through which one calendar object is written to, or removed from,
a server — the four write shapes the engine uses, and nothing else.
Picks the door a server's copies go through: the one write-channel decision
of the whole engine (EXO-90307).
Who a shared calendar belongs to, as far as the viewer may be told
(EXO-90237).
The owner of every calendar an account's session sees, as the server
answers it: what the owner cache keeps per account.
Gives every remote calendar a colour, deterministically.
What a calendar server product adds to the plain CalDAV the host speaks:
which registrations are that product's, the write channels it may use
besides CalDAV, and the per-account sessions it keeps outside the protocol.
The server flavours installed on this platform, and the one question the
host asks of them: which product a registration stands for.
A server-specific way of sharing a calendar collection with a colleague,
for a server on which the host's built-in mechanism — RFC 3744's
ACL method — is not how the server's own users share, and whose
every change the contribution can confirm by reading it back.The share channels installed on this platform, and the two questions the
share service asks of them: which mechanism a collection gets, and which
channel, if any, carries that mechanism.
A subscription a collection's name revealed: whose calendar it is.
How a calendar server product lays out, and lets eXo edit, the calendars
an account subscribes to — the calendars of somebody else that its
DAV listing shows under the account's own home, and that a share only
reaches once the colleague is subscribed.
The subscription channels installed on this platform, and the questions
the host asks of them: whose calendar a listed collection is, which uid a
principal addresses, and through which channel an account's subscriptions
are edited.
Carries an edit of a calendar — its rename, above all — to the user's
CalDAV server without waiting for the throttled sync.
A door, other than CalDAV, through which the copies of a server whose
registration declares a given
WriteChannel are written and removed.A collection's
DAV:acl as the server answered it to its owner
(EXO-90253), with the two facts that decide whether it may be written back.Whose a listed calendar collection is, to the eXo user whose account listed
it — the one answer the sweep, the calendar list and the event read-through
all act on, so that they cannot disagree about a collection.
The beans contributed to one of this add-on's extension points, read one
by one so that a contribution which cannot be created reads as absent
rather than failing every question asked of the extension point.
Which changes to a server registration have to reach the copies eXo has
already written, and which do not (EXO-89759).
What a resource says it supports, as
CalDavClient.capabilities(org.exoplatform.caldav.client.CalDavEndpoint, java.lang.String)
gathers it: the
compliance classes of its DAV header (RFC 4918 §10.1) and the
methods of its Allow header (RFC 9110 §10.2.1) — the two pieces of
evidence the sharing capability is selected from (EXO-90253).Puts a meeting into the calendars of the people invited to it, at the moment
it is created rather than at the next background sweep.
Removes every calendar copy of a meeting eXo has destroyed.
Carries an answer recorded in eXo out to the copy on the user's calendar
server.
Carries an edit made in eXo out to every calendar copy of that meeting that
already exists.
How the deployments seen writing into a server's accounts are held on the
server's own row (EXO-89824).
What the browser sends to hide a calendar shared with the user
(EXO-90239).
CalDAV over the JDK's own HTTP client, modelled line for line on
email-connector's
HttpCardDavClient — the hand-written client that
already works against the same BlueMind that defeated the browser — with
the disciplines the relay established carried over:
registry-only targets — endpoints are minted from the server
registry alone (HttpCalDavClient.endpoint(Long, String)), hrefs resolve against
that endpoint's authority, and a foreign-host href is refused;
no redirects — a declared server must not be able to bounce
this client's credentialed requests to another host, so the transport
never follows a 3xx (which also rules the well-known discovery flow out
by design: discovery starts at the registered base path instead);
explicit timeouts and a bounded body read, both
deployment-tunable;
no auth material anywhere near a log or an exception — every
message names the method and the URI, never a header.
The XML is parsed with doctypes and external entities disabled: the
payload comes from whatever server an administrator declared, which is
still attacker-influenced input, and a stock parser would happily read
files off this machine on its behalf.The one place a parser of foreign iCalendar is built, and the one place the
library is told how strict to be about what other people's software writes.
Answers one question: does the calendar object a server holds still
say what eXo would write for this event now?
Turns a parsed calendar object into the agenda event that will stand for it.
What comparing a copy against the object eXo would write concluded.
What a comparison can conclude.
Splices an event into the calendar object a server already holds.
What an attempted answer rewrite found.
A calendar object that cannot be read as iCalendar.
Reads a calendar object into the neutral
IcsEvent model — the exact
inverse of IcsWriter.Reads a remote calendar object into the occurrences it produces over a
window.
The small conversions the ICS engine needs, kept apart so the writer reads
as the shape of a calendar object rather than as string handling.
Builds the iCalendar object for one eXo event.
What a login-time attachment to the managed CalDAV server came to, one value
per branch of the rules and their failures.
The collection eXo copies space events into, which no channel may take for
a user's own calendar.
What the last pass over one user's copies found and moved.
What one relocation pass did to the copies already on the server, and whether
the destination change may be recorded as applied.
Where a user's space events are copied, and how that destination came to be.
What an MKCALENDAR answered — deliberately never a boolean "created".
The subscription channel of an account no contributed channel recognises:
no subscription is read in its listing, and nothing can be edited.
The flavour of a registration no contributed flavour recognises: a plain
CalDAV server, which writes through CalDAV only and keeps no session of its
own.
What the server answered to a PROPPATCH — the raw status and the statuses
of every propstat that did not grant its property.
What a conditional PUT answered.
Turns on Spring's scheduler for this add-on.
Which incremental-sync tier a collection's server can serve, read from one
Depth:0 PROPFIND (
supported-report-set, ctag, sync token) plus the
DAV response header.The incremental strategies of the plan, cheapest first.
Reads and writes the rolling summary of what a server has been seen doing,
stored as one string on its registration row.
One thing a server was seen doing, as the summary keys it.
What a summary is allowed to forget on one write.
How often a behaviour has been seen, and when it was last seen.
The caller's calendars agenda may offer "Share" on (EXO-90253).
What the browser sends to share a calendar with a colleague (EXO-90253):
the colleague's eXo login and nothing else.
A calendar of the caller's being shared, resolved and checked by the host:
the caller owns it in eXo, their account is connected, and it is bound to a
collection eXo created or to an imported one.
A share as the owner's grant or revoke knows it, with everything the
colleague's subscription needs and the audit line names.
What the host lends a
CalendarShareChannel for one operation: the
lock serialising edits of a collection's access, who eXo knows behind a
principal, and the subscription follow-up of a confirmed change.A colleague checked by the host for sharing: an active eXo user, not the
caller, connected to the same server registration under a recorded
principal that is not the caller's.
The reasons a share channel refuses to read, grant or revoke a share: the
codes a
CaldavShareException or an IllegalArgumentException
carries back to the owner.How a calendar server lets an owner grant somebody else access to a
collection, and whether eXo offers it there (EXO-90253).
How one attempt at a colleague's BlueMind subscription change ended.
The edits one session opened as a user can make to the calendars that user
subscribes to.
How one attempt at a colleague's BlueMind subscription change ended, and
what to do with the obligation's row.
What an RFC 6578 sync-collection REPORT answered: the hrefs that changed,
the hrefs that are gone, and the token to store for the next run.