Chaque pack apporte son propre calendrier de notification
build / Garde-fou (push) Successful in 10m45s
build / Images Harbor (catalog-sync, Dockerfile.catalog-sync) (push) Successful in 9m52s
build / Images Harbor (web, Dockerfile) (push) Successful in 10m0s

This commit is contained in:
hcornet committed 2026-09-12 11:02:02 +02:00
1 parent 032982cb28
commit 9debdcdf9c
57 files changed
+315 -108

No files matched your search

+11 -6
View File
@@ -15,14 +15,19 @@ indisponibles ».
Il reste une chose à faire de votre côté : **mettre des contacts dans le groupe**. Enclume
crée le groupe vide, faute de connaître vos utilisateurs.
### Les calendriers livrés par Centreon
### Chaque pack apporte son calendrier
`24x7`, `workhours`, `nonworkhours` et `none` existent dès l'installation. Ils apparaissent
dans le projet, avec leurs plages, pour qu'on voie à quoi les périmètres se réfèrent — mais
ils portent la mention « Centreon » et ne sont pas recréés : `TP;ADD` échouerait sur un objet
existant et interromprait le déploiement.
Un pack ne réutilise pas les calendriers du central : il crée le sien,
`TP-App-Apache-24x7`, `TP-HW-Printer-RFC3805-Heures-Ouvrees`. Ajuster les plages d'une
technologie ne touche alors qu'elle, et non tout ce qui pointait `24x7`.
Si votre central les a perdus, un bouton permet de forcer leur création.
Le rythme copié à la création est `24x7` pour ce dont la panne réveille quelqu'un,
`Heures-Ouvrees` sinon. Les plages restent modifiables ensuite, comme n'importe quel objet
du projet.
Si vous préférez viser un calendrier existant sur votre central — `24x7`, `workhours` —
saisissez-le dans le périmètre : il apparaîtra dans le projet marqué « Centreon » et ne sera
pas recréé, `TP;ADD` échouant sur un objet existant.
## Le principe