Package org.exoplatform.caldav.service
package org.exoplatform.caldav.service
-
ClassDescriptionWhat the server itself says about who owns each calendar an account sees — the fourth witness
CaldavOutboundService#ownershipOfhears (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.Turns an agenda event into what the ICS engine takes.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.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, throughCaldavCalendarShareServiceand 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.Who each connected eXo user is on their CalDAV server, and which eXo users are connected as a given principal (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.Deleting a personal calendar, on both sides.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.Name resolution as a seam.Brings the events of a materialised collection into the eXo calendar standing for it.What one reconciliation managed.Lands, for the mail reader, an invitation the user received by mail in their CalDAV-bound calendar (EXO-90848).Lands an invitation a user received by mail in their calendar (EXO-90848): the event the mail describes ends up on the user's CalDAV account and in the eXo calendar standing for it, under the identity the inbound sweep knows it by — with the answer the user gave, or without one when they only asked to add it — and leaves it when its organiser cancelled it.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.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.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 honestPARTSTAT=NEEDS-ACTION(EXO-89681).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.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.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.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).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).What each CalDAV server has been seen doing, and what its administrator has excused it for.The registry of CalDAV servers a deployment offers its users: what an administrator declares in the third section of the agenda administration page.Checks the address of a CalDAV server BEFORE the platform is made to connect to it.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).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.How often and how widely the engine synchronises, and who gets to say.Who a shared calendar belongs to, as far as the viewer may be told (EXO-90237).The server flavours installed on this platform, and the one question the host asks of them: which product a registration stands for.The server seeds installed on this platform (EXO-90737), and the one question the host asks of them on a first install: which rows, besides its own default, a fresh registry receives.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.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.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.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.