> ## Documentation Index > Fetch the complete documentation index at: https://docs.oximail.ch/llms.txt > Use this file to discover all available pages before exploring further. # Travail collaboratif > Exploiter les surfaces de collaboration : la planification de réunions (iTIP), le libre/occupé et la disponibilité, les fuseaux horaires, les notifications, les tâches et listes par défaut, les contacts et les CLI de réparation. Au-delà du courrier, OxiMail sert les agendas, les contacts, les tâches, les fichiers et le chat en JMAP, avec des passerelles CalDAV/CardDAV pour les clients classiques ([protocoles historiques](./legacy-protocols)). Cette page couvre les comportements qu'un exploitant doit comprendre, et les réglages et outils de réparation qui vont avec. ## Planification de réunions (iTIP) Quand des utilisateurs s'invitent, le serveur échange les messages de planification (REQUEST / REPLY / CANCEL) par courrier, selon la [RFC 5546](https://www.rfc-editor.org/rfc/rfc5546). Deux règles empêchent les ratés : * **Côté organisateur seulement.** OxiMail n'envoie de courrier de planification que pour les événements dont l'ORGANIZER se résout vers un **compte local** (RFC 5546 §3.2 : seul le serveur de l'organisateur envoie les invitations). Un événement arrivé comme invitation entrante ne réémet jamais de REQUEST quand le client du participant le réécrit, et supprimer une copie reçue ne diffuse jamais de CANCEL non autorisé : sur les chemins JMAP et CalDAV, en mode fermé. * **Émis après le commit.** Les messages iTIP ne partent qu'une fois la transaction qui a modifié l'événement réellement validée. Un conflit d'édition concurrente (`stateMismatch`) ou tout échec de validation n'émet **rien** : une invitation ne peut plus s'échapper pour un changement annulé, et un REQUEST de mise à jour porte toujours le contenu postérieur au changement, avec la `SEQUENCE` incrémentée. Les invitations entrantes (parties `text/calendar`) sont traitées à l'ingestion, y compris le style de propriétés paramétrées d'Outlook, et mettent à jour l'agenda du destinataire. ## Libre/occupé et disponibilité Trois surfaces de lecture répondent à « quand cette personne est-elle libre », toutes à travers une seule autorité d'énumération des occurrences (un événement récurrent se développe partout à l'identique, changement d'heure compris) : * **`Principal/getAvailability`** (JMAP) compose la disponibilité depuis les agendas auxquels le sujet est abonné et dont `includeInAvailability` vaut `all` ou `attending` ; un événement `privacy: "secret"` cache entièrement son temps occupé ; les détails d'un événement ne sont fournis qu'aux appelants qui détiennent un vrai droit de lecture : l'accès au libre/occupé n'implique jamais l'accès aux détails. Un appelant sans droit de libre/occupé sur aucun agenda du sujet reçoit un `forbidden` explicite, pas une disponibilité vide et trompeuse. * **La `free-busy-query` CalDAV** renvoie un `VFREEBUSY` de périodes occupées fusionnées (le provisoire compte comme occupé ; les événements libres/transparents, à la corbeille ou annulés sont exclus). * **L'interface de planification** d'un client s'appuie sur les mêmes données. ## Fuseaux horaires Les événements flottants (sans fuseau explicite) se résolvent par une chaîne de repli : **fuseau de l'événement → fuseau de l'utilisateur → défaut de l'organisation → UTC**. L'assistant capture le défaut de l'organisation à l'installation ([premier démarrage](../first-boot)) ; modifiez-le ensuite avec : ```bash theme={null} oximail tenant update --default-timezone Europe/Zurich ``` Les noms de fuseaux du registre Windows (venant d'Outlook, Exchange, eM Client) sont normalisés vers IANA sur chaque chemin d'ingestion, et les VEVENT exportés embarquent le `VTIMEZONE` correspondant pour que les clients stricts calculent des heures locales correctes. ## Notifications Les changements d'agenda produisent des objets `CalendarEventNotification` pour les personnes concernées : l'écriture d'un bénéficiaire sur un agenda partagé notifie le propriétaire, et un message de planification entrant notifie l'utilisateur concerné (REQUEST/CANCEL vers le destinataire, REPLY vers l'organisateur ; les changements de son propre fait sont tus). Les notifications sont inscrites au journal de changements et poussées : les clients les voient sans interroger. Les alertes (rappels) acceptent des déclencheurs relatifs et absolus, et sonnent une fois par occurrence grâce à une table de déduplication. ## Tâches Les listes de tâches suivent le modèle des agendas : méthodes JMAP, passerelle CalDAV VTODO, listes partagées. Chaque compte a exactement **une liste de tâches par défaut**, garantie par un invariant en base : un `Task/set` create sans `taskListIds` y atterrit. Les alertes de tâches acceptent un déclencheur absolu sans exiger d'échéance. ## Contacts Les contacts sont des ContactCards JMAP (RFC 9610) avec une passerelle CardDAV. Le serveur possède l'`uid` (un uid fourni par le client à la création est rejeté), et un `PUT` CardDAV qui créerait un doublon inter-sources d'un UID existant est refusé plutôt que dupliqué en silence. Les composantes de nom et d'adresse font l'aller-retour complet entre vCard et la forme JMAP. ## Partage Agendas, listes de tâches, carnets d'adresses et dossiers du drive partagent un seul modèle de droits (cartes `shareWith` indexées par principal, formes RFC 9670). Deux garanties utiles à l'exploitant : * **L'état par lecteur reste par lecteur.** Un bénéficiaire qui masque un agenda partagé (`isVisible`) ou met en favori un fichier partagé n'affecte que sa propre vue, jamais l'objet du propriétaire. * **Les bénéficiaires doivent être adossés à un humain.** Un droit accordé à une identité technique non connectable est rejeté à l'écriture sur tous les domaines : un droit qui ne pourrait jamais s'exercer est un mensonge dans l'ACL. La garde du drive des comptes partagés a sa propre surface : `oximail account custodian` (voir [multi-tenant](./multi-tenancy)). ## Réparations en un coup Les artefacts d'époque migration ont des commandes de réparation dédiées, **en simulation par défaut** : | Commande | Répare | | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `oximail account dedupe-folders (--account \| --all-accounts) [--apply]` | Les dossiers localisés en double à côté des dossiers de rôle (imports JMAP d'avant #131) : fusionne le courrier par le chemin d'appartenance canonique, rattache les sous-dossiers, détruit le doublon vidé. | | `oximail account dedupe-tasks (--account \| --all-accounts) [--apply]` | Les lignes de tâches en doublon exact issues d'imports répétés ; les lignes de même UID au contenu divergent sont listées, jamais touchées. | Les deux enregistrent des changements JMAP pour que les clients se resynchronisent proprement. Voir la [référence CLI](./cli).