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

Push notification rules should make sure to skip reply part of message #680

Open
JuniorJPDJ opened this issue Aug 18, 2020 · 4 comments
Open
Labels
A-Client-Server Issues affecting the CS API A-Push enhancement A suggestion for a relatively simple improvement to the protocol

Comments

@JuniorJPDJ
Copy link

ATM it's not specified and synapse sends notifications If someone was tagged inside message, that's being replied.
Example:
Screenshot_20200818_061853
At the screenshot both messages tagged me, when only first should.

This is part of this related issue:
element-hq/element-web#14943
Another part is matrix-org/matrix-spec-proposals#2735

@turt2live
Copy link
Member

this is somewhat of a divided topic ftr - some people actually want this. We'd almost certainly have to make it a push rule or whatever the equivalent is post-notifications rework.

@lieuwex
Copy link

lieuwex commented Aug 18, 2020

Just wanting to crosspost my comment here: matrix-org/synapse#6202 (comment)

I'm in favor of stripping the fallback before running the push rules against the message body.

@richvdh
Copy link
Member

richvdh commented Aug 26, 2020

worth mentioning here that the problem applies to @room notifs too.

@auscompgeek
Copy link
Contributor

FWIW I'm currently relying on the fact that the reply fallback includes the MXID of the user being replied to for push notifications. Any plan to strip the fallback when evaluating push rules should probably also keep this in consideration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Client-Server Issues affecting the CS API A-Push enhancement A suggestion for a relatively simple improvement to the protocol
Projects
None yet
Development

No branches or pull requests

5 participants