# Permissions et confidentialité du calendrier

Une permission relie un calendrier salarié et un collègue de la même société.

- Visibilité : `none`, `busy_only`, `details`.
- Réservation : `none`, `request`, `direct`.
- `can_view_tasks` est indépendant de la visibilité des rendez-vous.
- `can_edit_own_created_events` autorise uniquement la modification des événements créés par le bénéficiaire.

Une permission révoquée est conservée avec `revoked_at`; `active_slot` devient `NULL`. Un collègue ne peut jamais s'accorder lui-même une permission.

Les événements `private` et `busy_only` sont présentés comme « Occupé » aux autres utilisateurs. Les rôles administratifs ne révèlent pas leur titre, description, lieu, client, projet ou participants.

En mode `request`, aucun événement n'est créé avant l'acceptation. L'acceptation verrouille la demande, vérifie à nouveau le conflit et ne peut créer qu'un événement. En mode `direct`, le conflit est vérifié avant création et le créateur reste historisé.

Toutes les mutations utilisent un formulaire POST avec CSRF manuel. Les décisions de permissions et de demandes doivent rester dans les services métier, jamais dans Stimulus.