Мы разрабатываем Tabi – конструктор чат-ботов: автор соединяет блоки сообщений, вопросов и действий в схему диалога. В этой статье разберём одну настройку, которую легко выбрать неверно: кому принадлежит сохранённый ответ. Пример пригодится тому, кто собирает Telegram-бота для приёма заявок.
Представим мастерскую. Бот спрашивает, на какое занятие человек хочет прийти, как его зовут и как с ним связаться. Анна и Борис отвечают в разных личных чатах. Для примера используем вымышленные контакты DEMO-А и DEMO-Б.
Одна переменная – два разных способа хранения
У постоянной переменной contact есть имя и область хранения. Область «Бот» (Bot) означает одно значение на всех собеседников этого бота. Если Анна записала DEMO-А, а затем Борис записал DEMO-Б, последнее значение заменит предыдущее. При новом чтении общей переменной Анна получит DEMO-Б.
Область «Пользователь» (User) хранит значение отдельно для каждого профиля. Имя contact остаётся одинаковым, но у Анны и Бориса свои значения. Поэтому контакт человека сохраняем в User, а общий адрес мастерской можно хранить в Bot.
Рисунок 1. Ожидаемое поведение двух областей хранения по реализации Tabi. Это схема, а не результат проведённого теста с двумя людьми.
Как записать и потом прочитать свой контакт
Ответ на вопрос формы сначала находится в текущем диалоге. Бот помнит его между сообщениями, пока человек проходит анкету. Для сохранения контакта на будущее обращение нужен отдельный блок «Записать переменную».
После формы настройте этот блок: имя – contact, область – «Пользователь», значение – ответ на вопрос о контакте. Если переменная заранее объявлена в проекте, в её объявлении тоже должна стоять область User. Поле выбора другого пользователя оставьте пустым: в нашем примере нужен текущий собеседник.
Для проверки добавьте отдельную ветку «Показать мой контакт». В ней блок «Прочитать переменную» читает contact с областью «Пользователь» и кладёт результат, например, в saved_contact. Следующее сообщение выводит именно этот результат: «Ваш контакт: {{saved_contact}}».
Ветка чтения: «Показать мой контакт» → «Прочитать переменную» → сообщение с результатом.
Это важно: если просто повторить ответ из текущего диалога, бот может показать старую локальную копию. Такая проверка не выявит, что постоянная переменная ошибочно стала общей.
Контакт и заявка – разные вещи
Переменная хранит одно текущее значение. Таблица хранит отдельные обращения: Анна может оставить заявку на рисунок, а позже – на лепку. Если записывать только её последний выбор в одну переменную, история первого обращения пропадёт.
Для простого журнала в Tabi укажите таблицу в настройках формы и свяжите каждый вопрос с нужной колонкой. После завершения формы появится строка. Не добавляйте следом блок «Добавить запись» с той же заявкой: форма уже сохранила её, и получится вторая строка.
Ниже – реальный скриншот нашего учебного демо. Мы вручную собрали анкету из трёх вопросов и трижды прошли её с одного собственного Telegram-аккаунта. После каждого полного прохода в таблице владельца появилась отдельная строка с вымышленными ответами.
Рисунок 2. Три сохранённых учебных обращения одного аккаунта. Общая таблица демо подтверждает сохранение строк; она не подтверждает разделение доступа между двумя людьми.
Если бот будет показывать человеку его заявки, отдельно настройте доступ. В таблице User обычные блоки чтения и поиска с текущим профилем выбирают записи этого профиля. В общей таблице Bot такого ограничения нет: перед выдачей заявки сценарий должен проверить её владельца. Сам по себе ключ строки не даёт права читать чужие ответы. Владелец бота при этом видит данные в интерфейсе управления.
Проверка двумя аккаунтами: Анна → Борис → Анна
Проводите проверку в двух разных личных чатах с ботом. Нужны оба аккаунта: три прохода с одного не заменяют этот тест.
- Анна завершает анкету с контактом DEMO-А.
- Борис завершает свою анкету с контактом DEMO-Б.
- Анна открывает «Показать мой контакт». Бот заново читает постоянную переменную: ожидаем DEMO-А. Если он показывает DEMO-Б, проверьте область переменной и блоков чтения и записи.
- Борис вызывает ту же ветку: ожидаем DEMO-Б. Затем оба начинают новую анкету и отвечают на вопросы по очереди. Сверьте итоговые строки: каждая должна содержать ответы одного человека.
Если есть ветка показа заявок, попробуйте из чата Анны открыть запись Бориса через доступные кнопки или ввод. Бот не должен выдавать чужие данные. Это отдельная проверка: правильный контакт в переменной ещё не доказывает правильный доступ к таблице.
Что уже проверено в нашем примере
В Telegram-демо проверено сохранение трёх обращений одного аккаунта. Поведение User и Bot выше сверено с исходным кодом; проверку с двумя аккаунтами мы ещё не проводили. Демо не содержит ветки повторного чтения контакта. Поэтому мы показываем план проверки и ожидаемые ответы, а не выдаём их за полученный результат.
Этот разбор относится к личным чатам. У Telegram-группы в текущей реализации общий профиль чата – там сбор личных анкет нужно проектировать отдельно. Одновременное изменение общих данных, например числа свободных мест, тоже требует отдельного теста: выбор Bot сам по себе не защищает от конфликтов записи.
Автор – Даниил, команда Tabi. Текст подготовлен с помощью ИИ и проверен по реализации и сохранённым результатам учебного демо.
Комментарии