Attempt to clarify how event_match works
#3690
Conversation
| Unrecognised conditions MUST NOT match any events, effectively making | ||
| the push rule disabled. | ||
|
|
||
| `room`, `sender` and `content` rules do not have conditions in the same | ||
| way, but instead have predefined conditions. In the cases of `room` and | ||
| `sender` rules, the `rule_id` of the rule determines its behaviour. |
There was a problem hiding this comment.
I moved this stuff up from the bottom, because it seemed to be a bit lost under the sender_notification_permission definition.
(We seem to have lost the definition list formatting that the r0 spec used to use. I wonder if there are better ways to solve this.)
There was a problem hiding this comment.
Definition list formatting is probably something we can fix with writing style rather than formatting. We can discuss that elsewhere though.
| * The character `*` matches zero or more characters. | ||
| * `?` matches exactly one character. |
There was a problem hiding this comment.
Technically speaking, synapse allows you to specify a character range, with [a-z]. However, I can't see an occasion where that would ever be useful, and I'm more inclined to treat it as a synapse bug.
(I note that we don't specify character ranges for server_acls, where it also supports them)
| Unrecognised conditions MUST NOT match any events, effectively making | ||
| the push rule disabled. | ||
|
|
||
| `room`, `sender` and `content` rules do not have conditions in the same | ||
| way, but instead have predefined conditions. In the cases of `room` and | ||
| `sender` rules, the `rule_id` of the rule determines its behaviour. |
There was a problem hiding this comment.
Definition list formatting is probably something we can fix with writing style rather than formatting. We can discuss that elsewhere though.
| @@ -481,7 +486,7 @@ Definition: | |||
| } | |||
| ``` | |||
|
|
|||
| **`.m.rule.tombstone`** | |||
| **<a name="mruletombstone"></a>`.m.rule.tombstone`** | |||
There was a problem hiding this comment.
screen readers will have a hard time with this, but I'm happy to have this be converted into an issue instead of being fixed in this PR if you'd like though.
There was a problem hiding this comment.
hrm, sorry, I'm not up to date on how best to support screenreaders. My assumption was that an anchor like this would be very common, and ignored. Is there a better way of doing this?
There was a problem hiding this comment.
Fixing our heading structure so these become actual headings (and therefore implicit anchors we can use) would work best, but failing that we'd want to give some content to this like the permalink icons found other headings.
There was a problem hiding this comment.
I'm kinda struggling to envisage what exactly the failure mode is going to be here - if you have a clear idea, perhaps you could open an issue yourself?
I'm going to go ahead and merge this for now.
Fixes #3082, #2637, #3075.
Preview: https://pr3690--matrix-org-previews.netlify.app