-
Notifications
You must be signed in to change notification settings - Fork 252
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
feat(ffi): Allow to set the notification mode for a room #1967
Conversation
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.
Very nice!
The only other comment I would have is that it would be really nice to have unit tests for this logic, but we don't have unit tests anywhere in the FFI layer at the moment so that's a discussion to be had
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #1967 +/- ##
==========================================
+ Coverage 75.24% 75.30% +0.05%
==========================================
Files 147 148 +1
Lines 16052 16194 +142
==========================================
+ Hits 12079 12195 +116
- Misses 3973 3999 +26
☔ View full report in Codecov by Sentry. |
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.
Just skimming and passing by; this looks like a great thing to have in the non-FFI crate, as it implements more than just mapping to concepts existing in the non-FFI, including some lightweight logic. Would it make sense to move it to the non FFI crate? Then you could also more easily write tests, which would be sweet to have to make sure that this behaves as you'd expect.
d06320a
to
2c0e7cb
Compare
Hi @bnjbvr, I've moved the logic inside matrix-sdk (in fact this had also been requested by @jplatte). |
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.
@nimau I added 3 comments
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.
commented
edb136c
to
129607b
Compare
…al mentions and keywords rules are disabled.
129607b
to
1046a63
Compare
@giomfo: I've updated the code to reflect your comments. |
…t mode on the next sync response.
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.
Not a full review, just some remarks about the tests.
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.
Thanks for the PR. I didn't check the FFI bindings yet, I was focus on matrix-sdk
only.
I left few comments.
Please use Markdown in your documentation, and please try to expand your documentation with more than “replacing underscores by spaces from the method name” trick :-).
Hi @Hywan, thanks so much for your time and feedback. |
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.
Thanks! I've got a semi-large request to split the code (and PRs?), since NotificationSettings
does a lot; it would be pretty nice in terms of separating concerns, and making the PR review faster (and I'm willing to do the review of such a PR). See below, and let me know your thoughts.
@@ -167,3 +167,7 @@ callback interface SessionVerificationControllerDelegate { | |||
void did_cancel(); | |||
void did_finish(); | |||
}; | |||
|
|||
callback interface NotificationSettingsDelegate { |
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.
We've started calling those "listeners" recently:
callback interface NotificationSettingsDelegate { | |
callback interface NotificationSettingsListener { |
/// Sets a delegate. | ||
pub async fn set_delegate(&self, delegate: Option<Box<dyn NotificationSettingsDelegate>>) { | ||
*self.delegate.write().await = delegate; | ||
} |
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.
Can the delegate be set when constructing the NotificationsSettings
immediately? Would avoid the locking here, which would be nice.
} | ||
RoomNotificationMode::Mute => SdkRoomNotificationMode::Mute, | ||
}; | ||
let parsed_room_idom_id = RoomId::parse(&room_id) |
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.
typo: idom
?
) -> Result<(), NotificationSettingsError> { | ||
let mut ruleset = self.push_rules.read().await.clone(); | ||
let notification_settings = self.sdk_client.notification_settings(); | ||
let parsed_room_idom_id = RoomId::parse(&room_id) |
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.
(idom
here too)
// Listen for PushRulesEvent | ||
let push_rules_clone = push_rules.to_owned(); | ||
let delegate_clone = delegate.to_owned(); | ||
sdk_client.add_event_handler(move |ev: PushRulesEvent| { |
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.
Is this sufficient to get all the push rules since the creation of the room? are we sure at least one PushRulesEvent
is handled?
|
||
/// A high-level API to manage the client owner's push notification settings. | ||
#[derive(Debug, Clone)] | ||
pub struct NotificationSettings { |
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 is the large change I'm mentioning in the main review comment.)
This object mixes a few responsibilities:
- computing the actual rules from observing the raw Ruma
Ruleset
- interacting with the server to add/remove things
The former tends to not even make use of self
, in methods like get_custom_rules_for_room
, get_user_defined_room_notification_mode
, and a few others. This suggests a different implementation:
- create a wrapper struct for
Ruleset
, which only job is to interact with the innerRuleset
. - then have this
NotificationSettings
contain this wrapper (I don't think it should be the FFI's responsbility to own theRuleset
), and expose extra methods to interact with the server and update the ruleset.
That would blackbox the different problems, and if the Ruleset
's wrapper needs to interact with the server, it can use a command pattern and return a vec of commands to be applied by the client thereafter. Would probably help with testing, and also this would give us the possibility to split this PR into smaller ones that are easier to implement, test, review and merge 😁 : one PR for the Ruleset
wrapper and its tests, one for the NotificationSettings
. How does that sound?
// Get the current user defined mode for this room | ||
if let Some(mode) = | ||
notification_settings.get_user_defined_room_notification_mode(&parsed_room_id, ruleset) | ||
{ | ||
return Ok(RoomNotificationSettings::new(mode.into(), false)); | ||
} | ||
|
||
// If the user didn't defined a notification mode, return the default one for | ||
// this room | ||
let room = self | ||
.sdk_client | ||
.get_room(&parsed_room_id) | ||
.context("Room not found") | ||
.map_err(|_| NotificationSettingsError::RoomNotFound)?; | ||
|
||
let is_encrypted = room.is_encrypted().await.unwrap_or(false); | ||
let members_count = room.joined_members_count(); | ||
|
||
let mode = notification_settings.get_default_room_notification_mode( | ||
is_encrypted, | ||
members_count, | ||
ruleset, | ||
); | ||
Ok(RoomNotificationSettings::new(mode.into(), true)) |
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.
IMO this should be a method in the NotificationSettings
itself, there's still a bit too much logic for the FFI layer here.
I'm closing this PR, as it will be divided into several smaller PR. |
This PR implements the first part of #1959
It exposes a new
NotificationSettings
object in order to update the notification settings for a given room.The logic behind has been placed in matrix-sdk, with some unit tests.
The following MSC were considered:
MSC3987: Push actions clean-up
MSC3952: Intentional Mentions