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 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.
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).
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).
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.
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.
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.
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.
Gives each of a user's eXo personal calendars a collection of its own on the
remote server.
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.
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.
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).
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.
Who a shared calendar belongs to, as far as the viewer may be told
(EXO-90237).
Gives every remote calendar a colour, deterministically.
Carries an edit of a calendar — its rename, above all — to the user's
CalDAV server without waiting for the throttled sync.
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.
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.
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 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".
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.
How a calendar server lets an owner grant somebody else access to a
collection, and whether eXo offers it there (EXO-90253).
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.