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

Fixes Changing Account Settings > Notifications > Advanced Notifications on android causes discrepancies with web #3681

Merged
merged 8 commits into from
Jul 27, 2021

Conversation

langleyd
Copy link
Contributor

@langleyd langleyd commented Jul 15, 2021

Fixes #3672

This PR changes the existing logic, which continuously mutated the push rule definitions, updating them by trying to generalise the behaviour based on the PushRuleKind and handling exceptions to the definitions, overriding using the RuleId. The new implementation matches that on web, by having a static definition for each notification type.
The new StandardAction matches that on the web. As do the PushRuleDefinitions match those on the web.

I also updated the SDK to match the behaviour of the web based on the static rule definitions, whereby enabled request is always sent and actions request is sent if we are updating the actions(i.e. enabled==true).

I tested selecting each radio option, for each setting from android and they all match the requests(/reflect correctly in the ui) as on web.

@langleyd langleyd requested a review from bmarty July 15, 2021 15:16
@langleyd
Copy link
Contributor Author

This fix also needs to be incorporated into the V2 logic in #3673

Copy link
Member

@bmarty bmarty left a 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've made some comment, and I agree with you, it's not obvious to understand what's happening here...

@@ -130,10 +130,11 @@ class PushRulePreference : VectorPreference {
}
} else {
if (NOTIFICATION_OFF_INDEX == index) {
if (safeKind == RuleSetKey.UNDERRIDE || safeRule.ruleId == RuleIds.RULE_ID_SUPPRESS_BOTS_NOTIFICATIONS) {
if (safeKind == RuleSetKey.UNDERRIDE && safeRule.ruleId != RuleIds.RULE_ID_CALL) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand that it was not possible for safeRule.ruleId == RuleIds.RULE_ID_SUPPRESS_BOTS_NOTIFICATIONS to be true here. But why checking RULE_ID_CALL now?

To be honest, this code is really hard to follow, it misses some comment... :/

@@ -142,7 +143,7 @@ class PushRulePreference : VectorPreference {
&& safeRule.ruleId != RuleIds.RULE_ID_INVITE_ME
&& NOTIFICATION_NOISY_INDEX == index)

if (NOTIFICATION_NOISY_INDEX == index) {
if (NOTIFICATION_NOISY_INDEX == index && RuleIds.RULE_ID_ROOM_NOTIF != safeRule.ruleId) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same remark, should be nice to have some comment to explain why this code is necessary.

Copy link
Member

@bmarty bmarty left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the update. Yes I think it's globally better like that.

Some small remarks, else LGTM

* Get the highlight status. As spec mentions assume false if no tweak present.
*/
fun getHighlight(): Boolean {
return (getActions().firstOrNull { it is Action.Highlight } as? Action.Highlight)?.highlight ?: false
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can rewrite to
return getActions().filterIsInstance<Action.Highlight>().firstOrNull()?.highlight.orFalse()

enum class NotificationIndex(val index: Int) {
OFF(0),
SILENT(1),
NOISEY(2);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo?


import org.matrix.android.sdk.api.pushrules.Action

sealed class StandardAction(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rename to StandardActions ?

@@ -104,7 +105,7 @@ data class PushRule(
* Get the highlight status. As spec mentions assume false if no tweak present.
*/
fun getHighlight(): Boolean {
return (getActions().firstOrNull { it is Action.Highlight } as? Action.Highlight)?.highlight ?: false
return (getActions().firstOrNull { it is Action.Highlight } as? Action.Highlight)?.highlight.orFalse()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why you did not take my whole suggestion?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As sorry, read it too quickly

Copy link
Member

@bmarty bmarty left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the update!

@bmarty bmarty merged commit 00911a7 into develop Jul 27, 2021
@bmarty bmarty deleted the feature/dla/fix_account_notifications_discrepancies branch July 27, 2021 13:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Changing Account Settings > Notifications > Advanced Notifications on android causes discrepancies with web
2 participants