Actualizar servicio
Edita un servicio operativo existente desde el calendario de una ubicación y guarda en una sola operación sus datos, visibilidad, referencias públicas y dotación. En el runtime ES, el ejemplo principal es `Servicio de comidas Gran Via` en `Marea Gran Via`.
En este artículo
Usa esta guía cuando un responsable de operaciones necesite ajustar un servicio ya creado sin romper la relación entre calendario, reservas, plano, carta y equipo asignado.
El guardado directo de `services.update` está pensado para servicios futuros no recurrentes. Si el servicio pertenece a una serie recurrente, la pantalla deriva a la selección de alcance para acciones hermanas.
Antes de empezar
- Sesión iniciada en `Grupo Marea Demo` con organización y ubicación activas, por ejemplo `ORG_ID` y `LOCATION_ID`.
- Debe existir un evento de calendario de tipo `service` en la ubicación activa, como `Servicio de comidas Gran Via`.
- El usuario necesita `service:view`, `service:manage` y `staff-schedule:view`; para cambiar turnos de empleados también necesita `staff-schedule:manage`.
- Para guardar directamente, el servicio debe ser futuro y no recurrente.
- Si el servicio queda como `public`, debe mantener un `layout_id` y un `catalog_id` válidos, por ejemplo `Plano demo 1` y `Carta Gran Via`.
- Para capturas o pruebas que pulsen Guardar, usar un servicio temporal o un override controlado del runtime de documentación.
Instrucciones
- 1.
Abrir el editor del servicio
Entra desde el calendario o usa la ruta profunda `calendars/edit/:eventId?kind=service`. La pantalla debe abrir el formulario específico de servicio y cargar el bundle con evento base, recurrencia, roles requeridos y turnos asignados.
- 2.
Revisar datos generales
Comprueba título, descripción, fecha y horario. El título no puede quedar vacío y la hora de inicio debe ser anterior a la hora de fin. Si el servicio u ocurrencia ya empezó, el formulario queda bloqueado para este guardado directo.
- 3.
Definir la visibilidad
Elige si el servicio será `public` o `internal`. Un servicio `public` exige plano y catálogo porque puede alimentar superficies reservables. Un servicio `internal` queda como bloque operativo de calendario y planificación; al seleccionarlo, la pantalla limpia plano, catálogo y optimización.
- 4.
Actualizar la dotación
Ajusta roles requeridos y empleados asignados. Los requisitos y turnos se guardan dentro del mismo bundle del servicio, de modo que eliminar un rol o un turno del formulario elimina ese elemento del estado base al guardar.
- 5.
Guardar cambios no recurrentes
En un servicio futuro no recurrente, pulsa Guardar. Antylogic envía el bundle completo con `event`, `staff_requirements` y `staff_schedules`, actualiza el calendario y sincroniza ocurrencias actuales o futuras cuando corresponde.
- 6.
Revisar confirmación y avisos
Tras guardar, revisa la confirmación. Si aparecen `operation_warnings`, trátalos como avisos operativos posteriores al guardado, no como fallo automático de la actualización.
- 7.
Derivar servicios recurrentes
Si el servicio es recurrente, Guardar no ejecuta el `PUT` directo de `services.update`. La pantalla abre un modal para elegir si se cambia solo esa ocurrencia o los servicios futuros; esos casos pertenecen a `services.update-recurring-single` y `services.update-recurring-future`.
Validaciones y límites
- El evento debe existir en la ubicación activa y tener tipo `service`.
- Sin `service:manage`, la pantalla no permite editar ni guardar.
- Sin `staff-schedule:manage`, el guardado falla si se envían horarios de personal nuevos o existentes.
- El título es obligatorio y el rango horario debe ser válido.
- Para `public`, seleccionar plano y catálogo; para `internal`, no documentar el servicio como reservable ni visible en booking público.
- No se puede convertir a `internal` un servicio público con reservas activas actuales o futuras afectadas.
- Cada rol requerido debe tener `staff_role_id`, no duplicarse y usar conteos enteros de al menos 1.
- Cada horario de personal debe tener empleado, rol y rango válido.
- El backend rechaza cambios de tipo y cambios de horario o recurrencia que dejen reservas activas fuera de la nueva ventana del servicio.
- Los servicios recurrentes no se guardan por el `PUT` directo de esta acción.
Resultado esperado
Al finalizar, el servicio queda actualizado como `CalendarEventServiceBundle`: evento, visibilidad, referencias públicas cuando aplican, roles requeridos y turnos quedan sincronizados. La app invalida las vistas de calendario, bundle y ocurrencias para mostrar el estado actualizado.