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

Rejected reason is not visible in Element interface when the server is rejecting sent message via spam checker #1508

Open
MurzNN opened this issue May 28, 2021 · 7 comments
Labels
I18n T-Defect X-Needs-Product More input needed from the Product team X-Spec-Changes

Comments

@MurzNN
Copy link

MurzNN commented May 28, 2021

Description

When the Matrix server use some spam checker modules, they may fill the event.rejected_reason value to tell the user what exactly is the cause of rejection.

This info must be available in the HTTP response with rejection, but it isn't shown to user in Element user interface, they see only "Some of your messages have not been sent" phrase and that's all!

Steps to reproduce

  • Configure some custom spam checker module, that will reject message with filling the event.rejected_reason field.
  • Try to send messages, and see that you can't see this filled rejected reason.

Describe how what happens differs from what you expected.

Element should show the reasons of rejecting sending of messages, something like this:

Some of your messages have not been sent with reason: Message contains word "slave" that is in deny-list.

Version information

Element version: 07cf2f20fb25-react-890ac14090af-js-3a3be36f4c27
olm version: 3.2.3

@t3chguy
Copy link
Member

t3chguy commented May 28, 2021

rejected_reason is not a specced field in https://matrix.org/docs/spec/client_server/r0.6.1 so it is unlikely Element can support it, nor experimentally given it does not have an experimental prefix.

@MurzNN
Copy link
Author

MurzNN commented May 28, 2021

The rejected_reason field is available at the spam_checker's api in def check_event_for_spam(self, event), and in HTTP response it should be placed into the "error" field value (but Synapse not doing this because of issue noted here https://matrix.to/#/!XaqDhxuTIlvldquJaV:matrix.org/$ZRIlUgajYVSar0ViNfd2VZAhoxRgBKkiuJitQ22OH50?via=matrix.org&via=connecteu.rs&via=amorgan.xyz )
So now we have the HTTP 403 response like this:

{
  "errcode":"M_FORBIDDEN",
  "error":"Spam is not permitted here"
}

And Element can get the error text to show from here. When in Synapse this issue will be fixed, the templated text should be replaced to actual text.

@babolivier
Copy link

babolivier commented May 28, 2021

To correct what's been said and clear out any confusion, this isn't related to a field called rejected_reason. Spamchecker can reject an event with a reason by returning that reason string when checking the event for spam. Synapse returns this reason in the error key of a 403 Forbidden error response (edit: as shown in the example above).

@t3chguy
Copy link
Member

t3chguy commented May 28, 2021

Okay, but Element can't use error as it isn't internationalized to the user's language, it has to go off M_FORBIDDEN, maybe Synapse should use ORG_MATRIX_SYNAPSE_SPAM_NOT_PERMITTED

@t3chguy t3chguy added the I18n label May 28, 2021
@t3chguy
Copy link
Member

t3chguy commented May 28, 2021

Related issues for where we do (wrongly) use error element-hq/element-web#13767 element-hq/element-web#17410

@MurzNN
Copy link
Author

MurzNN commented May 28, 2021

Okay, but Element can't use error as it isn't internationalized to the user's language, it has to go off M_FORBIDDEN, maybe Synapse should use ORG_MATRIX_SYNAPSE_SPAM_NOT_PERMITTED

But the error text from custom modules may be very custom, and even contain variables (not as placeholders), so I think it can't be translated in all cases.
So maybe check it for list of exist translations, and if no match found - show as is?

@t3chguy
Copy link
Member

t3chguy commented May 28, 2021

That's not i18n friendly, Element doesn't check against any known error field values given they are not specced and are implementation-specific, plus as you said may contain variables, e.g @XYZ:server not in room in issue above

The spec really ought to consider a user's language and the server i18n errors, including in the spam checker module.

A translated generic Some of your messages have not been sent is better than a string that a user cannot understand whatsoever as it is in a foreign language to them.

@t3chguy t3chguy added the X-Needs-Product More input needed from the Product team label May 28, 2021
@t3chguy t3chguy transferred this issue from element-hq/element-web Apr 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I18n T-Defect X-Needs-Product More input needed from the Product team X-Spec-Changes
Projects
None yet
Development

No branches or pull requests

3 participants