-
Notifications
You must be signed in to change notification settings - Fork 396
Allow admins to see policy server-flagged events #18585
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
Conversation
@@ -0,0 +1,51 @@ | |||
# Client-Server API Extensions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussed in the #synapse-dev:matrix.org
room
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The term "spammy" doesn't feel like a real term to me... Can we just say "marked as spam"?
If you were looking for a short field name, policy_server_spam
seems fine.
e343076
to
32d605f
Compare
sorry for the force push: I thought I set this PR up for a clean merge of develop->PR, but forgot all of the important steps. |
"spammy" comes from the detail that the policy server doesn't technically get final say on whether the event is spam or not, despite that being the current implementation. It's also used in other places throughout the codebase, especially around the existing spam checker interfaces. I'd prefer to keep it as an invented word, but can change it if needed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some more iteration.
Could you also add some unit tests for this new field please?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This now looks good to me. Thanks for your patience!
if client_config.return_soft_failed_events: | ||
# The user has requested that all events be included, so do that. | ||
# We copy the list for mutation safety. | ||
events = events_before_filtering.copy() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a slight performance penalty to iterating over all events and then doing it again here, rather than moving the default case into the else
blocks.
But since is_soft_failed()
is very cheap, I think it's find to aid readability.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm also not personally concerned with a slight performance hit from asking for more stuff :p
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant more that the:
[e for e in events if not e.internal_metadata.is_soft_failed()]
isn't necessary in those cases.
Requires #18238Merged!Real diff: 881d521...travis/flag-ps-eventsPull Request Checklist
EventStore
toEventWorkerStore
.".code blocks
.