Шаблон откатывается при последовательном save двух шаблонов в одной сессии (без перезагрузки страницы)

[jorikfon]

Симптом (от клиента)

Цитата из DM от @shaxov92 (Vladimir, 2026-05-22):

ещё особенность работы модуля, сохраняю шаблон конфига если после него сразу отредактировать другой и сохранить первый не сохранится а откатится до последнего изменения

чтобы сохранить нужно после каждого конфига выходить из модуля и заходить обратно

Воспроизведение

1. Открыть админку модуля → вкладка «Шаблоны».
2. Открыть на редактирование template A, изменить содержимое, нажать «Сохранить» (видим зелёное «успешно»).
3. Не перезагружая страницу, открыть template B, изменить, сохранить.
4. → Состояние template A откатывается до того, что было ДО шага 2. Сохраняется только B.

Workaround: после каждого save выходить из модуля и заходить заново (полная перезагрузка страницы).

Окружение клиента

• MikoPBX 2026.1.223
• ModuleAutoprovision 1.66
• Браузер не уточнён — попросим у клиента, если потребуется при анализе.

Гипотезы корня (по приоритету проверки)

Гипотеза 1 — JS-стейт в табах (наиболее вероятно)

public/assets/js/src/module-autoprovision-index.js (компилируется в public/assets/js/module-autoprovision-index.js) держит DOM-кэш / textarea-состояние формы шаблона между переключениями. При save второго шаблона в payload AJAX-запроса попадает stale-содержимое первого, либо весь набор шаблонов целиком из кэша, и backend перезатирает A значениями «как было до правки A».

Что проверить:

• Как формируется payload при save в JS (вероятно один общий serializeForm на всю таблицу, а не на текущий ряд).
• Хранится ли в DataTable / Semantic UI tabs локальный snapshot всех строк.
• Очищается ли этот snapshot после успешного save (если нет — следующий save отправляет mix).

Гипотеза 2 — backend save перезаписывает весь набор

Если App/Controllers/ModuleAutoprovisionController.php (action типа saveTemplate) принимает не одну запись, а массив, и итерирует с UPDATE … WHERE id=… для каждого — то отправка stale-массива из JS триггерит перезапись A значениями из stale-кэша.

Что проверить:

• Метод save в ModuleAutoprovisionController.php — берёт ли он одну запись или массив.
• Если массив — то source of truth должен быть один (POST для текущего ряда), а не «весь набор + diff».

Гипотеза 3 — race на стороне Phalcon модели

При очень быстром последовательном save A→B возможно, что Templates::save() для B читает A из identity-map в состоянии «до save», и при flush'е перезаписывает. Менее вероятно (Phalcon обычно так не делает), но проверить стоит после первых двух.

Что не воспроизводилось у нас

На тест-PBX 172.16.32.94 эту последовательность не пробовали. Vladimir — единственный пока сообщил. Хорошо бы воспроизвести на стенде до фикса, чтобы зафиксировать reproducer (не «он сказал», а «вот скрин/HAR»).

Связанные задачи

• Race condition: pjsip перехватывает multicast PnP SUBSCRIBE раньше worker'а (требуется per-interface bind в Core/SIPConf) #17 — race-condition pjsip/PnP (другой баг от того же клиента, в работе).
• Не относится к PnP/race — это про admin UI шаблонов.

Приоритет

Средний. Не блокирует базовую функциональность (workaround «перезайти» работает), но раздражает в типичном сценарии массовой настройки нескольких шаблонов подряд.

CC: @boffart