Блин, написал ответ по-дискордовски, а потом посмотрел, кто пишет :)
Если это опять vk-бот, то советую посмотреть на то, имплементирует ли он ctx.author как Discord, тогда вместо user.first_name лучше брать ctx.author.first_name. Также, возможно, там работает type hint, как в discord.py, когда можно у параметра указать тип аргумента как member:discord.Member и он его автоматом превратит в инстанс этого класса, так что можно обращаться к нему со всеми его полями. В частности, в discord.py есть member.mention, который и надо использовать вместо @id.
Также надо использовать f-строки, вызов format на одну переменную вообще лишён смысла (а если там у юзера встретится {} в имени - то ещё и вызовет ошибку). Называть переменную list очень плохо, так как это название встроенного класса - можно где-нибудь прилично выстрелить себе в ногу.
В общем случае никак, так как эти боты работают от аккаунтов обычных пользователей. В том числе в теории это могут оказаться и взломанные аккаунты пользователей, которые уже раньше были в чате, вели себя нормально и прошли любые верификации.
Для каналов проблем нет, так как список подписчиков канала видит только админ.
alextimson, чтобы это была именно команда, нужен класс discord.ext.commands.Bot, который порождён от discord.Client и расширяет его функционал. В discord.Client нет команд, но их можно имитировать путём парсинга сообщений в event on_message. События с именем info в Discord не бывает, поэтому подобая функция будет делать совсем ничего.
Зачем в reviews есть ФИО, если они есть в persons? И не стоит где-то называть person, а где-то user. Если их функции различаются, то это должны быть разные сущности. Возможно расширение функций, когда, например, user может быть клиентом магазина, а может быть владельцем/менеджером, тогда это могут быть таблицы с допсвойствами и ссылкой на первичную таблицу по id (user-shop_client и user-shop_manager).
У сообщения стопудово должно быть время отправки, по которому надо будет сортировать чат. Или можно по id сообщений сортировать, если id будут возрастать со временем. id и получателя, и отправителя не имеют смысла, если чат тет-а-тет, тут имеет смысл id только отправителя, который может совпадать с user_id в чате, а может быть user_id менеджера магазина (заодно можно, чтобы в магазине работали разные люди и могли независимо общаться с пользователями). Клиенту магазина можно не показывать имя менеджера, а показывать название магазина.
Хорошо бы навести порядок в английском. Massage - это массаж, правильно message; magazine - это журнал, правильно shop. ФИО лучше сортировать нормально (а не ставить отчество первым, хотя, конечно, в базе порядок столбцов неважен, но если уж проектировать, то аккуратно) и быть готовым к тому, что многие категорически не хотят его заполнять и будут ставить минусы или "нет" везде, кроме имени - короче, лучше разрешать их пустые значения. Вместо patronymic чаще всего поле называют middle name - это покрывает и понятие отчества, и дополнительные имена, существующие во многих культурах и странах.
products_id - почему во множественном числе? Лучше вообще единообразие: либо таблицы называются единственным числом (тогда красиво выглядят отсылки user.id, user.name), либо множественным (users), а ссылки как раз через единственное число.
При именовании таблиц и колонок не стоит использовать разный регистр и лучше воздерживаться camelCase. Всё равно большинство баз имеют регистронезависимые имена сущностей (и из-за этого приходится дополнительно напрягаться иногда). И не надо пробелов в именах. Названия типа name magazine тоже плохие, так как (на этом примере): 1. пробел вместо подчёркивания; 2. и так понятно, что магазин, по имени таблицы; 3. порядок в названии лучше более естественный; 4. это вообще-то магазин, а не журнал (см. выше) - короче, правильно просто name, даже не shop_name и уж тем более не name_shop. Вообще, это тот случай, когда уместен некоторый перфекционизм.
У покупателей часто бывает больше одного адреса: они могут заказывать домой, на работу, на дачу, в квартиру родителей итд. Имеет смысл также вынести в отдельную таблицу. Также часто выносят названия городов и областей в отдельные таблицы (словарь), а в адресе указываются id (через выпадающий список). Но если это учебная задача или проект небольшой, то можно не заморачиваться. Всё равно часто изменения таких вещей происходят с пониманием масштабов и специфики работы. Например, московские магазины могут при выборе Москвы предлагать улицу из списка, а при выборе подмосковных населённых пунктах - позволять вводить улицу вручную, так как база улиц каждого областного СНТ - это нереально.
Короче, улучшать можно почти до бесконечности. Особенно если дорасти до уровня всяких авито.
Лучше всего видимо всё же MediaWiki, если основная функция всё же развитая вики-разметка с шаблонами и категорями.
Скорее всего, в чистом виде готового решения не будет и придётся что-то допиливать или пересмотреть варианты решения (например, вместо хронологической линейки генерировать список годов с вики-ссылками на события).
Очень много чего интересного можно сделать с помощью шаблонов, правда, придётся мыслить по-шаблоновски :) Можно, например, посмотреть, как в Википедии устроен шаблон Location, который добавляет в статью координаты со ссылкой на карты (наверное, можно подпилить, чтобы выдавать всплывающее окошко с картой, например).
Как вариант, можно сделать класс с нужными данными пользователя, как class User в вышеприведённом примере, и держать в скрипте словарь, который отражает chat_id в User. При этом если chat_id нет в ключах - создавать новый пустой User (скорее всего, его можно создавать прям при /start. Отдельная задача - сохранять данные между перезапусками (в базе или в файле)
Или можно сделать аналогичную таблицу в базе и всё записывать в неё, при необходимости доставать, или можно хранить в скрипте выгрузку из базы, при чтении данных использовать её, при записи изменять и её, и базу. В общем, есть варианты.
Если там не нужны хорошие вычислительные ресурсы (например, распознавание голоса делается не нейронкой на localhost, а каким-то сервисом) - то вполне нормальная идея.
Владислав Лысков, строго говоря, процедура там и правда замороченная: надо зарегистрировать бизнес, пройти его верификацию, делегировать провайдеру сервиса право управлять WA-аккаунтами от имени этого бизнеса...
Xrey Monstrikov, на самом деле если хочется сделать что-то интересное - есть миллион более осмысленных и даже ценных задач. Например, можно попробовать помочь проекту https://t.me/ruarxive
Эти смс бесплатны только для тебя, но не для владельцев сайтов. Я даже больше скажу - для владельцев сайтов они дороже, чем для обычного рядового абонента мобильных операторов.
С Business API ничего на самом деле особо сложного, там главная беда для многих очень хотевших в том, что это не бесплатно. К провайдеру привязка может быть разве на уровне используемого протокола, а номер можно между ними мигрировать. На самом деле все партнёры WA хотят, чтобы подключались именно через них, поэтому стараются всячески помочь пройти все эти процедуры потенциальным клиентам.
Слава, это скорее свойство не Java или PHP, а свойство тех сфер, где они применяются: в Java заметный перекос в сторону энтерпрайза с повышенными требованиями и совсем другими бюджетами.
mkone112, это явно ирония над неким расхожим образом, которого иногда серьёзно, а иногла в шутку придерживается некоторая сторона. Так-то дофига народу мешает с грязью и питонистов, и джавоведов, и растаманов. У любого языка есть хейтеры, которые свои чувства проецируют на соответствующих разработчиков.
Steven Eaton, надо обе задачи сделать с асинхронными библиотеками и не страдать ерундой, потому что синхронный код в любом случае несовместим с асинхронным циклом событий. У телебота уже появилась асинхронная версия.
