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

Can't confirm bans for messages without text #198

Closed
dsent opened this issue Dec 14, 2024 · 3 comments · Fixed by #199
Closed

Can't confirm bans for messages without text #198

dsent opened this issue Dec 14, 2024 · 3 comments · Fixed by #199

Comments

@dsent
Copy link

dsent commented Dec 14, 2024

Every time I try to confirm bans for messages with no text (blocked by one of the meta checks), I get this: error: failed confirmation ban: failed to get clean message: no original message found in callback msgsData. The problem is probably that the messages are internally identified by their text. But this doesn't have to be that way for the messages with buttons created by the bot itself.

Can we embed some kind of ID to the buttons, so the message doesn't have to be identified by the text, if it's created by the bot itself, not forwarded to the admin group?

@dsent
Copy link
Author

dsent commented Dec 14, 2024

This way, we can also avoid ambiguity in case that different users send exactly the same message. Having the same text, they will have different internal IDs.

@umputun
Copy link
Owner

umputun commented Dec 14, 2024

This is not the accurate assumption of how it is currently working. Both message ID and user ID have already been passed in; see

func (a *admin) parseCallbackData(data string) (userID int64, msgID int, err error) {
.

The issue is about a different thing—failed text extraction should not fail the confirmation flow.

The reason we need to extract this text and not just use msg_id from the callbackData is the ability to handle admin reports made not just by the /spam reply but also by the admin's forwarding. I don't recall why exactly, but I believe in this case TG doesn't keep the ID of the original message, and matching on text was the only way to find the original.

@umputun
Copy link
Owner

umputun commented Dec 14, 2024

The ticket was closed automatically by PR, but please give it a try and confirm. I think it will work the way you expected, as the change was rather trivial.

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

Successfully merging a pull request may close this issue.

2 participants