Групповое удаление бэкапов (docs/changes/013): - страница «Резервные копии»: чекбоксы, «выбрать все», панель «Выбрано: N / Удалить / Снять выбор» вместо фильтров, подтверждение, итог удаления; - backups.delete_many: все ключи проверяются до удаления, удаление параллельное; UI POST /backups/delete-many, API POST /api/v1/backups/delete; - выбор строк в app.js обобщён (data-select) для устройств и бэкапов. Поддержка CHR (docs/changes/014): - у CHR нет /system/routerboard (HTTP 400): устройство больше не считается недоступным, версия FW не показывается, обновление FW пропускается; - «есть обновление ROS» определяется строгим сравнением версий (на канале long-term последняя версия может быть старше установленной); - в таблице указана причина недоступности: авторизация / ошибка ответа / нет соединения. Тесты: 11 из 11. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
1.4 KiB
План: 014 — поддержка CHR и строгое сравнение версий ROS
Проблема: два новых устройства (CHR в Yandex Cloud и OpenStack) помечались offline, хотя ping, трассировка и авторизация проходили.
Причина: на CHR нет раздела /system/routerboard — REST отвечает HTTP 400 no such command or directory (routerboard), а get_status считал это сбоем устройства.
Решение: ros/operations.py::get_routerboard — отсутствие раздела (400 + «no such command») означает «нет RouterBOARD firmware», не ошибку; используется в статусе и обновлении FW. Второе: на канале long-term «последняя» версия (7.23.7) старше установленной (7.24), а сравнение «версии отличаются» показало бы это как обновление — введено строгое сравнение version_newer (учитывает alpha/beta/rc). Ещё: в таблице причина недоступности различается — «Ошибка авторизации» (401), «Устройство ответило ошибкой» (другие HTTP), «Нет соединения».