Package org.exoplatform.caldav.model
package org.exoplatform.caldav.model
-
ClassDescriptionWhether this deployment chooses the CalDAV server on its users' behalf, and which one.Outcome of probing a CalDAV account server-side, before anything is stored: a stable code the connect drawer translates — the same codes the browser probe historically produced, so the drawer's messages did not change when the probe moved behind the platform (where BlueMind's missing CORS headers stop mattering).What the relay answers the browser with: the upstream server's status and body — DAV logic like 207 multistatus parsing or the 412 conflict discipline lives in the caller, so statuses pass through untouched — under a response-header allow-list, with advertised hrefs rewritten into relay space and the credential-related statuses already translated (an upstream 401 means the stored CalDAV credentials are stale, never that the eXo user is unauthenticated, so it must not travel as a 401).One DAV request the browser asks the platform to relay to a declared CalDAV server.A CalDAV server registration, as an administrator declared it: where the server lives and how it is presented to users.How often and how widely eXo synchronises CalDAV accounts.What deleting an eXo calendar would also do on the remote side, so the page can say it before the user confirms.What kind of owner a calendar shared with the user belongs to (EXO-90275): a person, or a resource such as a room or a pool vehicle.Who an eXo personal calendar is shared with on its CalDAV server, as the server's access control list says at the moment of asking (EXO-90253).One principal a calendar is shared with.Which of BlueMind's two kinds of published link a calendar was published as.What a principal's entries grant.Who a principal on a calendar's access list is, to eXo.An eXo user, as a sharee or a candidate.A calendar pair as the service layer handles it.What one calendar's synchronisation is doing, in the terms a user can act on.The lifecycle of one calendar pair.A calendar the user hid, and the handle to show it again.One thing a server was seen doing to a copy eXo pushed to it.Everything the ICS engine needs about one event, and nothing else.A calendar user on the copy: an organizer or an attendee.One reminder, as agenda holds it: a quantity and the unit it counts in.Where an administrator wants the meeting copies of a server to land.What one pass over the copies eXo pushed found, and what it did about it.One calendar object's identity across the two sides, as the service layer handles it.One thing a server has actually been seen doing to the copies eXo pushes to it, with how often, and whether an administrator has excused it.One write eXo owes to one calendar copy and has not managed to make.What eXo still owes one calendar copy.A calendar of the connected account, in the shape agenda expects from any connector.What listing the connected account's calendars actually produced, failures included.What reading the connected account over a period actually produced, failures included.One occurrence read from a remote calendar, in the shape agenda displays.The behaviours a CalDAV server can be excused for, named in code.Which way a divergence between a copy and what eXo writes points.What ticking a quirk actually does — and the two answers are not the same kind of thing.Which side of the pair created the collection, and therefore which side owns its existence.