Actualizar una ocurrencia recurrente
Permite editar solo una ocurrencia futura de un servicio recurrente en Marea Gran Via sin cambiar la serie completa. El cambio se guarda como calendar_override y se refleja en la ocurrencia operativa materializada.
En este artículo
Usa esta guía cuando una fecha concreta de un servicio recurrente necesita otro horario, título, visibilidad o dotación, pero el resto de la serie debe seguir igual.
La opción correcta en el modal Editar servicio recurrente es Solo este servicio. Servicios futuros pertenece a otro flujo.
El resultado vigente no es un servicio puntual ni una división de la serie: el evento base se conserva y la diferencia queda registrada como excepción de la ocurrencia.
Antes de empezar
- Sesión iniciada en Grupo Marea Demo y ubicación Marea Gran Via.
- Permisos de ubicación service:view, staff-schedule:view y service:manage.
- Una ocurrencia futura de un servicio recurrente abierta con occurrenceStart en la ruta de edición.
- La ocurrencia no debe haber empezado en la zona horaria Europe/Madrid.
- Si el servicio queda público, layout_id y catalog_id deben seguir siendo válidos; optimization_config_id es opcional.
- Si ya hay reservas activas, el nuevo horario debe cubrirlas y no se puede cambiar el servicio de público a interno.
Instrucciones
- 1.
Abre la ocurrencia desde el calendario
En Calendario de servicios, localiza una fecha futura del servicio recurrente y abre esa ocurrencia concreta. La navegación debe llegar al editor con eventId, kind=service y occurrenceStart; si falta occurrenceStart, la pantalla no puede identificar qué fecha se quiere modificar.
- 2.
Revisa el editor prellenado
El editor carga el bundle del servicio con occurrence_start. Si esa fecha ya tenía una excepción, el formulario aparece con los datos aplicados a esa ocurrencia y muestra el aviso de edición de una sola ocurrencia.
- 3.
Modifica solo campos válidos
Ajusta los datos necesarios para esa fecha, como título, descripción, horario, visibilidad o roles requeridos. Para servicios públicos, conserva plano y carta válidos; los roles no pueden estar vacíos ni duplicados y las cantidades deben ser al menos 1.
- 4.
Guarda como Solo este servicio
Pulsa Guardar y, en el modal Editar servicio recurrente, elige Solo este servicio. La app envía POST /calendar-events/{eventId}/split con action="update", scope="single", occurrence_start y bundle.
- 5.
Confirma la excepción
Al guardar, el sistema vuelve al calendario y recarga las ocurrencias. Al reabrir la misma fecha, GET /service-bundle debe devolver override y la pantalla debe mostrarla como excepción de la serie, no como un servicio puntual separado.
Validaciones y límites
- POST /split solo acepta action="update" y scope="single" para esta guía.
- occurrence_start y bundle son obligatorios, y la ocurrencia debe pertenecer realmente a la serie.
- El nuevo rango horario debe cumplir new_start < new_end.
- Una ocurrencia ya iniciada queda bloqueada con error.calendar.service.started_locked.
- Con reservas activas, la API rechaza horarios que las dejan fuera con error.calendar.service.reservations_range.
- Con reservas activas, la API rechaza pasar de público a interno con error.calendar.service.reservations_internal.
- El guardado crea o actualiza calendar_override y reemplaza calendar_override_staff_requirement; no documentar calendar_override_staff_schedule como comportamiento garantizado.
Resultado esperado
El calendar_event recurrente se mantiene como serie base. La fecha editada queda registrada como calendar_override, se materializa o actualiza su service_occurrence con override_id y el calendario se invalida para mostrar la ventana efectiva de esa ocurrencia.