En la instancia que recibe la configuración, abre Administración › Instancia y operaciones › GOLIVE. El origen debe estar declarado (véase «Declarar el origen de un GOLIVE»).
Elegir
La página lista lo que el origen puede proporcionar, módulo por módulo: scripts, formularios, procesos, categorías, artículos y servicios del catálogo, configuración de los tickets, ajustes de configuración, plantillas de correo y de notificación, traducciones personalizadas, idiomas… Para encontrar un elemento:
- Buscar (barra de la cuadrícula): una parte de la etiqueta, de la clave, del módulo o del tipo, sin importar mayúsculas ni acentos;
- los encabezados de columna ordenan y filtran (módulo, tipo, activo, modificado el);
- Modificado desde: solo lo que cambió en el origen desde una fecha.
Marca los elementos que quieras. No hace falta marcar las dependencias: elegir un servicio incluye su categoría, sus artículos, sus formularios, sus procesos y sus scripts. Un elemento que no se elige por sí solo no tiene casilla. Las casillas marcadas siguen marcadas de una página o de un filtro a otro; Elementos elegidos indica cuántos hay.
Previsualizar
Vista previa de la selección lee el paquete en el origen y lo compara con esta instancia, sin escribir nada aquí. Para cada elemento:
- la acción prevista: nuevo, modificado o idéntico; para un elemento modificado, las diferencias indican lo que cambia;
- las discrepancias: un aviso no impide nada; una discrepancia bloqueante impedirá la aplicación. Las más habituales: un grupo, una cuenta, un buzón o un grupo de máquinas que no existe aquí (créalo, o vincúlalo en «GOLIVE — origen»), un módulo ausente o sin licencia aquí;
- «añadido como dependencia»: el elemento no se marcó, lo necesita un elemento elegido.
Algunos campos pueden diferir legítimamente entre instancias, como la planificación de un disparador. La vista previa muestra el valor del origen y el de aquí; marca Tomar el valor del origen para reemplazarlo y después Guardar. Sin marcar, se conserva el valor de aquí.
Algunas reglas propias de ciertos elementos:
- Ajustes de configuración: solo se proponen los previstos para pasar de una instancia a otra (contraseñas, bloqueo, tema, nombre de la aplicación…). Las direcciones, el correo saliente, las conexiones y los secretos siguen siendo propios de cada instancia y nunca aparecen;
- Plantillas de correo: el remitente (dirección y nombre) es un campo a elegir; por defecto se conserva el valor de aquí;
- Traducciones: solo aparecen las traducciones modificadas en el origen, con todos sus idiomas;
- Idiomas: la activación se copia, en un sentido y en el otro; el idioma por defecto es un campo a elegir, y el de aquí nunca se desactiva;
- Consultas: una consulta reservada a grupos solo pasa si todos sus grupos existen aquí (mismo código); si no, la vista previa la bloquea, para no abrirla nunca a todos;
- Menús: las entradas se sustituyen por las del origen; una entrada cuyo grupo falta aquí queda reservada a los administradores. Las asignaciones del menú (a quién se muestra) siguen siendo las de aquí;
- Paneles: solo se proponen los paneles compartidos con grupos; un grupo de compartición añadido aquí se conserva;
- Redirecciones y páginas de presentación: una redirección desactivada o una página despublicada aquí sigue así; en cambio, una desactivación en el origen se copia.
- Scripts: se emparejan por su identificador (el mismo en cada instancia), si no por su nombre; un script que ya está aquí se actualiza, nunca se vuelve a crear. Cada script pasa los controles de la pantalla de creación de esta instancia (nombre, timeout de 24 horas como máximo, 10 reintentos como máximo, contenido de 2 MB como máximo, parámetros) y su nombre no debe pertenecer ya aquí a otro script. Si no, la vista previa muestra «Script descartado» con el motivo y el valor en cuestión: ese script no se aplica, el resto del GOLIVE sí. Un proceso que usa un script descartado se descarta con él («Descartado junto con un elemento del que depende»).
- Scripts de un mismo GOLIVE: también se comparan entre sí, en el orden en que se aplicarán. Dos scripts nuevos con el mismo nombre: el primero se aplica, el segundo se descarta («otro script ya lleva este nombre») en lugar de fusionarse con el primero. Un script que retoma el nombre que deja otro script del mismo GOLIVE, o cuyo nombre lo toma un script aplicado antes que él, se descarta igual. La aplicación descarta exactamente lo que descartó la vista previa: promueve ese script en un GOLIVE siguiente.
- Tareas programadas: solo se promueven los disparadores de las tareas incluidas en la aplicación y las ejecuciones de consulta. El cron de cada disparador es un campo a elegir: se conserva el de esta instancia, salvo si marcas el del origen. Una tarea o un disparador nuevo llega desactivado y figura en «a reactivar»; una tarea desactivada aquí sigue así. Una tarea del código ausente en esta instancia (módulo desactivado) bloquea. Las llamadas a URL y las planificaciones creadas por otros módulos (scripts, conectores, disparadores del catálogo) no se promueven.
- Ventanas de exclusión de tareas: se copian como el resto; una ventana desactivada aquí sigue así.
- CMDB: se promueven los tipos de objeto (campos, traducciones, derechos por grupo) y los tipos de relación; un campo o un derecho añadido aquí se conserva, un derecho nunca se retira y un grupo ausente aquí bloquea. Un campo con el mismo nombre pero de otro tipo de dato bloquea. Los tipos nativos (usuarios, grupos…) nunca se promueven. Las fichas introducidas a mano se eligen una a una (las que recopila un conector se quedan en cada instancia): sus valores completan los de aquí (un valor vacío en el origen no borra nada), las relaciones se añaden; una ficha citada que aún no está aquí se deja de lado y se enlaza en el GOLIVE que la trae. Los adjuntos no se promueven.
- Conector GLPI: solo se promueven las correspondencias de campos, nunca la conexión (dirección, tokens, agente, planificación). Crea y conecta primero la fuente aquí, con el mismo identificador (slug); una correspondencia modificada exige una recopilación completa.
- Cambios: tipos de cambio (con su proceso de aprobación) y periodos de congelación; un CI del perímetro de una congelación ausente aquí bloquea, para no congelar nunca más ni menos de lo previsto.
- Release: puntos de la plantilla de checklist e instancias de destino del despliegue; un equipo avisado ausente aquí deja el de aquí.
- Supervisión: reglas de tratamiento de alertas y de vinculación de CI, ventanas de mantenimiento manuales futuras. Una regla llega desactivada y figura en «a reactivar»; su fuente de eventos, propia de cada instancia, se enlaza por su nombre. Todo lo que cita (fuente, CI, categoría, prioridad, grupo) debe existir aquí; si no, bloquea.
- Organizaciones: tipos de vinculación; el que rige la visibilidad de los tickets nunca se cambia. Las reglas que llenan grupos a partir de las organizaciones se quedan en cada instancia.
- Base de conocimiento: bases, categorías, etiquetas y artículos elegidos uno a uno. Un artículo llega en el estado del origen (publicado aquí si lo está allí), con sus idiomas, sus etiquetas y sus adjuntos, en las mismas direcciones; un artículo archivado aquí sigue así. Una modificación en curso aquí se conserva, pero ya no podrá publicarse tal cual: la vista previa lo indica, igual que una base cuyo acceso se abre. Un adjunto de más de 20 MB, o de un tipo rechazado aquí, bloquea. La documentación entregada con la aplicación nunca se promueve: cada instancia la importa desde su versión. Los derechos sobre las bases se quedan en cada instancia.
- Sincronización de directorios y filtros de buzón: una regla de sincronización AD viaja sin su conexión, propia de cada instancia — creada aquí, llega inactiva y con la conexión vacía, a completar antes de activarla; si ya existe, conserva la suya. Sus correspondencias de grupos y las de Microsoft 365 apuntan al grupo con el mismo código; si falta aquí, el elemento queda bloqueado. Los orígenes nuevos y los filtros de buzón llegan desactivados, a reactivar tras comprobarlos; un filtro se vincula al buzón del mismo nombre, o al que le asignes. El registro de correos excluidos se queda en cada instancia.
- CRM: campos personalizados, valores de listas, reglas de duplicados, roles de equipo, reglas de puntuación de prospectos, competidores, pipelines (con sus etapas), reglas de aprobación de presupuestos y de traspaso de pedidos, ajustes de la base instalada, secuencias, territorios y planes de comisiones. Un producto, una familia o un rol CRM citado por una regla debe existir aquí con el mismo código (el catálogo y los roles no se promueven): si no, la vista previa bloquea. Una etapa de pipeline añadida aquí se conserva. También bloquean: un campo con el mismo código y otro tipo, un plan de comisiones ya usado aquí cuyas reglas cambiarían, una secuencia en curso de la que se quitarían pasos, un territorio padre que crearía un bucle. Las tasas de cambio, las tarifas, los roles y los equipos siguen siendo propios de cada instancia.
Una vista previa congelada
La vista previa conserva el paquete tal como se leyó, con su huella: la aplicación cubrirá exactamente lo que se muestra, aunque el origen cambie mientras tanto. Para tener en cuenta un cambio del origen o una discrepancia resuelta aquí, vuelve a hacer una vista previa. Las vistas previas recientes siguen disponibles desde la página GOLIVE. Para aplicarla, véase «Aplicar un GOLIVE y consultar el historial».