- убраны клиент бота, транспорт обновлений, отправитель сообщений, сборка входа при старте, секция настроек и зависимость go-telegram-bot-api; из конвейера ушла доставка ответа отправителю — исход виден опросом готовности. Колонки адресата и значение источника остались в схеме: применённые шаги не переписываются - шаг 202608140003 запрещает пустого владельца у аудиозаписи и у файла; существующие строки он не проверяет, и это принято сознательно — искать их надо запросом до выкладки - ревью нашло два пред-существующих дефекта, оба закрыты: пустой второй ответ распознавателя стирал сохранённую расшифровку, а пустая расшифровка перестала быть заметной вместе с убранной доставкой. Попутно поднят golang.org/x/image до v0.45.0 — красный шаг vulns, воспроизводился и на чистом master
81 lines
7.5 KiB
Markdown
81 lines
7.5 KiB
Markdown
## Why
|
|
|
|
Сервис принимает записи двумя входами, и входы расходятся в главном: у записи,
|
|
пришедшей из приложения, есть владелец, а у записи, пришедшей от бота, владельца
|
|
нет и быть не может — связи чата с учётной записью сервис не ведёт. Пока такие
|
|
записи заводятся, правило «каждая запись принадлежит человеку» действует
|
|
наполовину: половину записей оно накрывает, а другую половину обходит, и каждое
|
|
решение о владельце приходится писать с оговоркой про бота.
|
|
|
|
Основной вход сегодня — приложение, и работа идёт над ним. Второй вход при этом
|
|
стоит денег на каждой задаче: его нельзя не учитывать в приёме, в доставке
|
|
ответа, в отборе записей и в настройках. Убираем его, чтобы модель стала одной, и
|
|
убираем **временно**: бот вернётся, когда появится связь чата с учётной записью.
|
|
|
|
## What Changes
|
|
|
|
- **BREAKING**: вход Telegram убирается целиком. Бот не поднимается, записи от
|
|
него не принимаются, ответ в чат не уходит.
|
|
- **BREAKING по смыслу, а не по разбору**: настройки входа Telegram и список
|
|
допущенных к боту людей уходят из конфигурации. Файл, где их забыли, сервис
|
|
примет молча — незнакомые ключи разбор настроек не судит, — но значить они
|
|
перестают что бы то ни было. Секцию убирает человек при выкладке.
|
|
- У записи появляется владелец на правах обязательного, и держит это хранилище:
|
|
колонка владельца у записи и у файла перестаёт принимать пустое значение. Завести
|
|
ничью запись нельзя ничем — ни приёмом, ни конвейером, ни рукой в панели.
|
|
- Из конвейера уходит доставка ответа отправителю: единственный оставшийся вход
|
|
узнаёт исход опросом готовности и из панели владельца. Вместе с доставкой
|
|
уходят правило про недоставленный ответ и обязанность остановки сообщать
|
|
отправителю.
|
|
- Наблюдатель видит один поднятый вход вместо двух.
|
|
- Записи с источником Telegram, если они есть, остаются нетронутыми: колонки чата
|
|
и ответного сообщения из схемы не убираются, и ни одна запись не удаляется.
|
|
Записей **без владельца** в базе при этом нет — так ответил владелец сервиса, и
|
|
на этом стоит обязательность колонки; прогон нового шага схемы на копии боевой
|
|
базы проверяет это до выкладки.
|
|
|
|
## Capabilities
|
|
|
|
### New Capabilities
|
|
|
|
Новых нет: изменение убирает поведение, а не заводит.
|
|
|
|
### Modified Capabilities
|
|
|
|
- `intake`: уходит требование о признаке включения входа Telegram; требование о
|
|
видимых наблюдателю входах говорит об одном входе.
|
|
- `pipeline`: уходят требования о недоставленном ответе и об обязанности всякой
|
|
остановки сообщать отправителю — адресата у сообщения не осталось. Взамен
|
|
появляется требование, что конвейер наружу не обращается вовсе. Из выборки
|
|
воркера и из требования о держателе захвата уходят оговорки про записи без
|
|
владельца и про ответ отправителю.
|
|
- `access`: запись без владельца перестаёт быть возможной. Правило «чужую запись
|
|
не отдают» не меняется; остаётся и правило «пустой владелец не совпадает ни с
|
|
одной записью» — оно запрещает спрашивать ничьим именем, а не заводить ничью
|
|
запись.
|
|
- `storage`: колонка владельца у аудиозаписи и у файла перестаёт принимать пустое
|
|
значение — это новый шаг схемы. Приведённая копия файла получает владельца
|
|
своей записи. Из требований о подъёме на чистом каталоге и о пароле владельца
|
|
уходит «обоими входами».
|
|
|
|
## Impact
|
|
|
|
- **Код**: удаляются клиент бота, отправитель сообщений, разбиение длинного
|
|
текста, заглушка отправителя, транспорт бота, сборка входа при старте и договор
|
|
об отправителе сообщений. Из службы расшифровки уходят приём записи от бота и
|
|
отправка текста в чат.
|
|
- **Настройки**: секция `[telegram]` целиком и ключ `server.users_while_list`
|
|
(имя ключа в коде написано с опечаткой, и она здесь воспроизведена намеренно —
|
|
искать в боевом файле надо именно его).
|
|
- **Зависимости**: `go-telegram-bot-api/telegram-bot-api/v5` уходит из манифеста.
|
|
- **Хранилище**: один новый шаг схемы, и он делает колонку владельца обязательной
|
|
у аудиозаписи и у файла. Применённые шаги не переписываются, колонки чата и
|
|
ответного сообщения остаются на месте вместе с записями, которые их заполнили.
|
|
- **Наблюдение**: метка `telegram` у признака поднятого входа больше не
|
|
выставляется.
|
|
- **Документы**: паспорт теряет потребителя и два типовых сценария; инвариант о
|
|
белом списке бота уходит из памятки; модель угроз теряет вход.
|
|
- **Задачи беклога**: `telegram-account-link` и `bot-api-only-through-bot-client`
|
|
теряют предмет до возвращения бота. Судьбу их решает владелец — это изменение
|
|
их не закрывает.
|