Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] PTB detect anonymous send channel as 777000 = Telegram User ID #2810

Closed
mrismanaziz opened this issue Dec 7, 2021 · 5 comments
Closed
Labels

Comments

@mrismanaziz
Copy link

Steps to Reproduce

Expected behaviour

I want the ptb to fix the detect id to the chat id of the channel or none

Actual behaviour

I am a user of Telegram beta version 3.8.0, in Telegram beta there is a new feature, namely sending messages in groups using channels. when I use message info from the channel I'm on. ptb detects the channel as id 777000 which means as telegram, where the id is id lord. I can be an admin in a group that I am not an admin what if the group management bot adds the telegram id to the decorator is admin.

Operating System

Telegram Beta v8.3.0

Version of Python, python-telegram-bot & dependencies

Version of Python: 3.9
Version of python-telegram-bot: 13

Relevant log output

No response

Additional Context

No response

@Poolitzer
Copy link
Member

Poolitzer commented Dec 7, 2021

Proper support for Bot API 5.5 will be added in #2808, but that didn't change the way channels send messages in groups. All you have to check is if sender_chat from the Message object is set to something. I didn't really get the rest of your question, if my answer doesn't clear it up, try rephrasing your question please.

@mrismanaziz
Copy link
Author

mrismanaziz commented Dec 7, 2021

i mean, when i send message in group by using channel, provided by telegram beta version 3.8.0, when i use sender_chat , channel user id is detected as 77700 where it is telegram id not channel chat id
photo_2021-12-08_05-05-05

@clot27
Copy link
Member

clot27 commented Dec 8, 2021

Actually Bot API 5.5 haven't implemented in PTB yet, so how can you expect a bug related to new API in PTB?

@Bibo-Joshi
Copy link
Member

You're apparently not using the Message.sender_chat attribute, bot the from_user attribute. Consider this minimal example:

import html
import json

from telegram import ParseMode
from telegram.ext import Updater, MessageHandler, Filters


def callback(update, _):
    update.effective_message.reply_text(f'<pre>update = {html.escape(json.dumps(update.to_dict(), indent=2, ensure_ascii=False))}</pre>', parse_mode=ParseMode.HTML)


def main():
    updater = Updater('TOKEN')
    updater.dispatcher.add_handler(MessageHandler(Filters.all, callback))
    updater.start_polling(drop_pending_updates=True)
    updater.idle()


if __name__ == '__main__':
    main()

This just replies the raw json-data received from Telegram to each message. If you run this example, you'll notice that the json data lists Telegram with id 777000 as from, but lists the channel as sender_chat - the latter is exactly what the API update promises.
You can see an example of this at https://t.me/roolstest_offtopic.

You are somewhat right about the fact that 777000 should not be reported as from user for those messages: https://core.telegram.org/bots/api-changelog#november-4-2020 states

For backward compatibility in non-channel chats, the field from in such messages will contain the user 777000 for messages automatically forwarded to the discussion group […]

which strictly speaking doesn't cover the new send-by-a-channel messages. However, changing this would be the job of Telegram - PTB has no say in this. You can file a report at bugs.telegram.org or github.com/tdlib/bot-api.
Then again, this is for backwards compatibility only anyway, so you should just use sender_chat when that field is set.

@mrismanaziz
Copy link
Author

oke thanks you

@github-actions github-actions bot locked and limited conversation to collaborators Dec 15, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants