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

"Official" Bot commands with trailing usernames don't work in groups #139

Closed
delivrance opened this issue Oct 14, 2018 · 9 comments
Closed

Comments

@delivrance
Copy link
Member

Example:

/start@pyrogrambot

Workaround:

Filters.command(["start", "start@pyrogrambot])

Would be nice to have it automatically handled.

@fenilgandhi
Copy link

I would like to work on it.

@delivrance
Copy link
Member Author

Sure, if you have any idea feel free to propose a pull request

@delivrance delivrance added this to the v1.0.0 milestone Jun 15, 2019
@ColinShark
Copy link
Member

I don't know if this would work, but would it make sense to just use regex?

Filters.command("start", "/") and in the background it creates the compiled regex:

f"{prefix}{command}(@{username)?" which would return /start(@samplebot)? and trigger on both with and without the @samplebot at the end.

@delivrance
Copy link
Member Author

@ColinTheShark The issue is how to get the bot username to be used inside the filter, automatically.

While we have the message instance available in the filter's callback, we can do message._client.get_me().username, or call get_me() somewhere in the client and store the username somewhere and then do message._client.username in the filter. Both solutions are ugly because they make use of non-public attributes (_client).

Maybe we can just match (?i).+@\w+bot?

@ColinShark
Copy link
Member

Using such a generic Regex would possibly catch updates meant for other clients 🤔

If my bot were ColinSharkBot, /hi@AhoyBot would also be caught by my bot and unintentionally react to it.

(Commenting here parallel to the discussion in the chat to have it in the Issues, too)

@AVee
Copy link

AVee commented Oct 19, 2019

Would it make sense to always call get_me() on Client.start() and make that info available? I guess there are more scenarios where that would be useful...

@delivrance delivrance removed this from the v1 milestone Aug 3, 2020
@tshipenchko
Copy link

tshipenchko commented Feb 19, 2021

I think that will work good

regex_patern = r'^\/(command)+(\@username_of_bot\w*(_\w+)*)?([ \f\n\r\t\v\u00A0\u2028\u2029].*)?$'

https://gist.github.com/tshipenchko/42b81fb53bd52ca7034eb6f2b1b99799

Commands like that will handle

/command
/command arg1 arg2
/command@username_of_bot
/command@username_of_bot arg1 arg2 

but
/command@other_bot
won't handle

@CustomIcon
Copy link
Contributor

Hi i have fixed it by modifying a filters.command()
https://nekobin.com/wilemoyepe.py

and example code for this will be

# import modified filters.command()
import command

@Client.on_message(command('start'))
async def func(_, message):
    print(message.command)
    await message.reply('hi')

but dan i suggest not to use this in pyrogram itself since it kinda slows the client down. this could be one of the few solutions for this

@murlakatamenka
Copy link

Thought that's already landed in the stable version of Pyrogram only to discover it actually hasn't yet 😢

That's an inconvenience, but not a huge issue though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

7 participants