Choisir et prévisualiser un GOLIVE

Sur l'instance qui reçoit le paramétrage, ouvrez Administration › Instance et exploitation › GOLIVE. La source doit être déclarée (voir « Déclarer la source d'un GOLIVE »).

Choisir

La page liste ce que la source peut fournir, module par module : scripts, formulaires, processus, catégories, articles et services du catalogue, paramétrage des tickets, réglages de configuration, modèles de courriel et de notification, traductions personnalisées, langues… Pour retrouver un élément :

• Rechercher (barre de la grille) : une partie du libellé, de la clé, du module ou du type, sans se soucier des majuscules ni des accents ;
• les en-têtes de colonne trient et filtrent (module, type, actif, modifié le) ;
• Modifié depuis le : seulement ce qui a changé dans la source depuis une date.

Cochez les éléments voulus. Les dépendances n'ont pas besoin d'être cochées : choisir un service emporte sa catégorie, ses articles, ses formulaires, ses processus et leurs scripts. Un élément qui ne se choisit pas seul n'a pas de case. Les cases cochées le restent d'une page ou d'un filtre à l'autre ; Éléments choisis en donne le nombre.

Prévisualiser

Aperçu de la sélection lit le paquet sur la source et le compare à cette instance, sans rien y écrire. Pour chaque élément :

• l'action prévue : nouveau, modifié ou identique ; pour un élément modifié, les différences indiquent ce qui change ;
• les écarts : un avertissement n'empêche rien ; un écart bloquant empêchera l'application. Les plus courants : un groupe, un compte, une boîte mail ou un groupe de machines introuvable ici (créez-le, ou liez-le dans « GOLIVE — source »), un module absent ou sans licence ici ;
• « ajouté comme dépendance » : l'élément n'a pas été coché, il est nécessaire à un élément choisi.

Certains champs peuvent légitimement différer entre les instances, comme la planification d'un déclencheur. L'aperçu montre la valeur de la source et celle d'ici ; cochez Prendre la valeur de la source pour la remplacer, puis Enregistrer. Sans case cochée, la valeur d'ici est gardée.

Quelques règles propres à certains éléments :

• Réglages de configuration : seuls ceux prévus pour passer d'une instance à l'autre sont proposés (mots de passe, verrouillage, thème, nom de l'application…). Les adresses, la messagerie sortante, les connexions et les secrets restent propres à chaque instance et n'apparaissent jamais ;
• Modèles de courriel : l'expéditeur (adresse et nom) est un champ au choix, la valeur d'ici est gardée par défaut ;
• Traductions : seules les traductions modifiées dans la source apparaissent, avec toutes leurs langues ;
• Langues : l'activation est recopiée, dans un sens comme dans l'autre ; la langue par défaut est un champ au choix, et celle d'ici n'est jamais désactivée ;
• Requêtes : une requête réservée à des groupes ne passe que si tous ses groupes existent ici (même code) — sinon l'aperçu la bloque, pour ne jamais l'ouvrir à tous ;
• Menus : les entrées sont remplacées par celles de la source ; une entrée dont un groupe manque ici est réservée aux administrateurs. Les attributions du menu (à qui il s'affiche) restent celles d'ici ;
• Tableaux de bord : seuls les tableaux partagés avec des groupes sont proposés ; un groupe de partage ajouté ici est gardé ;
• Redirections et pages vitrine : une redirection désactivée ou une page dépubliée ici le reste ; une désactivation dans la source, elle, est recopiée.
• Scripts : retrouvés par leur identifiant (le même dans chaque instance), sinon par leur nom ; un script déjà ici est mis à jour, jamais recréé. Chaque script passe les contrôles de l'écran de création de cette instance (nom, timeout de 24 heures au plus, 10 tentatives au plus, contenu de 2 Mo au plus, paramètres) et son nom ne doit pas déjà être porté ici par un autre script. Sinon l'aperçu affiche « Script écarté » avec la raison et la valeur en cause : ce script n'est pas appliqué, le reste du GOLIVE l'est. Un processus qui utilise un script écarté est écarté avec lui (« Écarté avec un élément dont il dépend »).
• Scripts d'un même GOLIVE : ils sont aussi confrontés entre eux, dans l'ordre où ils seront appliqués. Deux nouveaux scripts du même nom : le premier est appliqué, le second est écarté (« un autre script porte déjà ce nom ») au lieu d'être fusionné dans le premier. Un script qui reprend le nom qu'un autre script du même GOLIVE abandonne, ou dont le nom est pris par un script appliqué avant lui, est écarté de même. L'application écarte exactement ce que l'aperçu a écarté : promouvez ce script dans un GOLIVE suivant.
• Tâches planifiées : seuls voyagent les déclencheurs des tâches livrées avec l'application et les exécutions de requête. Le cron de chaque déclencheur est un champ au choix : celui de cette instance est gardé, sauf si vous cochez celui de la source. Une tâche ou un déclencheur nouveau arrive désactivé et figure dans « à réactiver » ; une tâche coupée ici le reste. Une tâche du code absente de cette instance (module désactivé) bloque. Les appels d'URL et les planifications créées par d'autres modules (scripts, connecteurs, déclencheurs du catalogue) ne sont pas promus.
• Fenêtres d'exclusion des tâches : recopiées comme le reste ; une fenêtre coupée ici le reste.
• CMDB : les types d'objet (champs, traductions, droits par groupe) et les types de relation passent ; un champ ou un droit ajouté ici est gardé, un droit n'est jamais retiré, et un groupe absent d'ici bloque. Un champ de même nom mais d'un autre type de donnée bloque. Les types natifs (utilisateurs, groupes…) ne sont jamais promus. Les fiches saisies à la main se choisissent une à une (celles qu'un connecteur collecte restent à chaque instance) : leurs valeurs complètent celles d'ici (une valeur vide dans la source n'efface rien), les relations s'ajoutent ; une fiche citée qui n'est pas encore ici est laissée de côté et reliée au GOLIVE qui l'apporte. Les pièces jointes ne sont pas promues.
• Connecteur GLPI : seules les correspondances de champs passent, jamais la connexion (adresse, jetons, agent, planification). Créez et connectez d'abord la source ici, sous le même identifiant (slug) ; une correspondance changée demande une collecte complète.
• Changements : types de changement (avec leur processus d'approbation) et périodes de gel ; un CI du périmètre d'un gel absent d'ici bloque, pour ne jamais geler plus ou moins que prévu.
• Release : points du modèle de checklist et instances cibles de déploiement ; une équipe prévenue absente d'ici laisse celle d'ici.
• Supervision : règles de traitement des alertes et de rattachement CI, fenêtres de maintenance manuelles à venir. Une règle arrive désactivée et figure dans « à réactiver » ; sa source d'événements, propre à chaque instance, se lie par son nom. Tout ce qu'elle cite (source, CI, catégorie, priorité, groupe) doit exister ici, sinon elle bloque.
• Organisations : types de rattachement ; celui qui règle la visibilité des tickets n'est jamais changé. Les règles qui remplissent des groupes à partir des organisations restent à chaque instance.
• Base de connaissances : bases, catégories, étiquettes et articles choisis un par un. Un article arrive dans l'état de la source (publié ici s'il l'est là-bas), avec ses langues, ses étiquettes et ses pièces jointes, sous les mêmes adresses ; un article archivé ici le reste. Une modification en cours ici est gardée, mais ne se publiera plus telle quelle : l'aperçu le signale, comme une base dont l'accès s'ouvre. Une pièce jointe de plus de 20 Mo, ou d'un type refusé ici, bloque. La documentation livrée avec l'application n'est jamais promue : chaque instance l'importe depuis sa version. Les droits sur les bases restent à chaque instance.
• Synchronisation des annuaires et filtres de boîte mail : une règle de synchronisation AD part sans sa connexion, propre à chaque instance — créée ici, elle arrive inactive, connexion vide, à compléter avant de l'activer ; présente, elle garde la sienne. Ses correspondances de groupes et celles de Microsoft 365 visent le groupe de même code ; s'il manque ici, l'élément est bloqué. Les sources nouvelles et les filtres de boîte mail arrivent désactivés, à réactiver après vérification ; un filtre se rattache à la boîte de même nom, ou à celle que vous lui liez. Le journal des courriels exclus reste à chaque instance.
• CRM : champs personnalisés, valeurs de listes, règles de doublons, rôles d'équipe, règles de note des prospects, concurrents, pipelines (avec leurs étapes), règles d'approbation des devis et de passage de relais, réglages du parc installé, séquences, territoires et plans de commission. Un produit, une famille ou un rôle CRM cité par une règle doit exister ici sous le même code (le catalogue et les rôles ne sont pas promus) : sinon l'aperçu bloque. Une étape de pipeline ajoutée ici est gardée. Bloquent aussi : un champ de même code d'un autre type, un plan de commission déjà utilisé ici dont les règles changeraient, une séquence en cours dont des étapes seraient retirées, un territoire parent qui ferait une boucle. Les taux de change, la grille de prix, les rôles et les équipes restent propres à chaque instance.

Un aperçu figé

L'aperçu garde le paquet tel qu'il a été lu, avec son empreinte : l'application portera exactement sur ce qui est montré, même si la source change entre-temps. Pour tenir compte d'un changement de la source ou d'un écart réglé ici, refaites un aperçu. Les aperçus récents restent accessibles depuis la page GOLIVE. Pour l'appliquer, voir « Appliquer un GOLIVE et consulter l'historique ».