Telegram бот для оператора шиномонтажки

[Nelfimov]

С чем связан запрос на фичу?

Необходимо разработать Telegram бота для оператора шиномонтажки

Расскажите как вы это себе видите

Основные цели бота:

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

Используем https://github.com/tgsnake/core для Telegram API Архитектура: clean - https://github.com/atls/serverless-yandex

Приложите пример реализаций

https://github.com/atls/migration-bot/tree/refactor/promise-to-wizard

Plan:

• [x] сделать фильтр на использование бота, зашить в константу
  • [x] по АЙДИ
  • [ ] по ЮСЕРНЕЙМ?
• [ ] уведомление о новой записи
  • [ ] подтвердить запись
  • [ ] отменить запись
• [ ] информация о записи:
  • [x] список всех записей
  • [ ] подбробная информация конкретной записи
• [ ] по запросу открывать запись на сегодняшний и завтрашний день?

[kirill-ivanovvv]

• по запросу открывать запись на сегодняшний и завтрашний день

@Nelfimov подскажи пожалуйста что значит, не понимаю чей запрос будет

можно автоматически открывать запись на каждый следующий день (завтра) и выводить кнопку типа "Не открывать запись на завтра"

[Nelfimov]

Оператор нажимает кнопку в боте - ему бот высылает список записей на сегодняшний и завтрашний день

[kirill-ivanovvv]

@Nelfimov а я правильно понял, что tgsnake-adapter переиспользовать мы не можем. сейчас расчерчиваю новый сервис opertator-bot и соответственно создаю новый tgsnake-adapter. много функционала будет повторяться

[TorinAsakura]

@Nelfimov а я правильно понял, что tgsnake-adapter переиспользовать мы не можем

Нет.

сейчас расчерчиваю новый сервис opertator-bot и соответственно создаю новый tgsnake-adapter. много функционала будет повторяться

Адаптер не может быть переиспользован, так как задача в гексагональной архитектуре, которую выполняет адаптер - это доступность, а если ты завяжешь на адаптер несколько частей системы, то, при попытке от него избавиться ты зацепишь всю систему, а не только тот кусок, который должен был взаимодействовать с адаптером

[kirill-ivanovvv]

Текущий статус

• расчертил сервис
• подключил основные модули
• вывел команду /start

  Дальнейшие планы

• продетализирую модули, посмотрю что еще гарантированно пригодатся - буду копировать с booking-telegram-bot
• буду работать по плану, начну с фильтра. испольование бота должно быть доступно только операторам. их список буду зашивать либо в константу либо в env

  Актуальная ветка

  https://github.com/torin-asakura/shdvor/tree/feat/operator-bot

[kirill-ivanovvv]

Текущий статус

• сделал абстрактный класс для юс-кейсов операторов
• в абстрактном классе - фильтр для операторов
• провел i18n

  Дальнейшие планы

  

  Актуальная ветка

• https://github.com/torin-asakura/shdvor/tree/feat/operator-bot

[kirill-ivanovvv]

Текущий статус

• ничего результирующего не сделал, вчерашние изменения откатил.
• в субботу допишу, извиняюсь.

  Дальнейшие планы

  

  Актуальная ветка

• https://github.com/torin-asakura/shdvor/tree/feat/operator-bot

[kirill-ivanovvv]

Текущий статус

• прописал команду /get_appointments - возвращает все записи за блиайшие 48 часов, выглядит вот так:
• расширил i18n для operator-bot
• начал писать функцию уведомления оператора о новой записи
• общение между сервисами делаю при помощи fetch и api-context в каждом сервисе
• на счет вот этого пунка не знаю, нужен ли он. кажется сейчас список достаточно подробный, чтобы дополнительно по каждой записи запрос не делать. можно в списке всех записей выводить сжатую информацию, и тогда добавить запрос расширенной информации. покачто оставлю как есть.
  • 

    Дальнейшие планы

• закончить оповещение оператора о новой записи
• нужно с сообщением об оповещении выводить две инлайновые кнопки - согласовать и отменить запись.
• соответственно их функционал

Актуальная ветка

• https://github.com/torin-asakura/shdvor/tree/feat/operator-bot

---

@Nelfimov подскажи пожалуйста, как еще можно обращаться к БД.

• сейчас все общение сделал через ОРМ. а ОРМ у нас только в одном сервисе - поэтому общаюсь через этот сервис, через api-запросы
• как я понял второй инстанс ОРМ создать не получится, потомучто вокруг ОРМ жирный контекст, который мы не продублируем, поэтому ОРМ на проекте может быть только одна
• думал о том, что можно делать SQL-запросы к БД напрямую, но сильно в этот вариант зарываться не стал - так возможно сделать?
• может быть есть еще какието варианты?

[kirill-ivanovvv]

Текущий статус

• расчертил api-context для operator-bot

Дальнейшие планы

• после подтверждения записи клиентом отправить фетч на operator-bot/api-context (notify-operator-use-case)
• оповестить оператора сообщением с двумя кнопками
• написать логику для этих кнопок
• после подтверждения отправить фетч на booking-telegram-bot/api-contxt с оповещение о результате подтвержения (notify-client-use-case)
• добавить api-роут в booking-telegram-bot/api-contxt для
  • записи результат в бд (колонка isApproved)
  • оповещение клиента о результате подтверждения оператором

Актуальная ветка

• https://github.com/torin-asakura/shdvor/tree/feat/operator-bot