-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
MM-50354 - do not show push disabled notification once acknowledged #7495
MM-50354 - do not show push disabled notification once acknowledged #7495
Conversation
app/screens/home/channel_list/categories_list/header/header.test.tsx
Outdated
Show resolved
Hide resolved
app/utils/push_proxy.ts
Outdated
@@ -23,7 +37,14 @@ export function canReceiveNotifications(serverUrl: string, verification: string, | |||
} | |||
} | |||
|
|||
export function alertPushProxyError(intl: IntlShape) { | |||
const handleAlertResponse = async (buttonIndex: number, serverUrl: string) => { | |||
if (buttonIndex === 0) { |
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 is only one button, and always sets the ack, so... how would it show the warnings in the rest of the product? Shouldn't be two buttons like "OK" and "Dont remember me anymore"? And maybe that second button only available when checking the warning after login? 0/5
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 way I approached is like, for users that are already logged in the warning will still show once logged in and they will be able to discard it once clicked "ok". For those who log in for the first time the warning will show just once and will reduce the annoying part of showing it in different places and several times.
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.
@esethna Thoughts about this?
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.
@esethna so, there are basically three places where we inform user that the push can not be received due to configuration: initial alert window on loading the app, channels header alert icon, servers list alert icon.
Current implementation works like this:
- first app loading shows users the alert window notifying that due to configuration the push alerts can not be received. Users clicks ok, log in and then the header bar and the server show the icon which if clicked will show the Alert again, and again, etc.
My approach with the changes in this PR is:
- For existing users that are already logged in in a server which has the push disabled, the alert icon in the header and server list will be shown, once they click it and the alert window is shown and click 'ok' acknowledging the warning, these alert icons won't show again.
- For new users the initial alert window will be shown, but once discarded (which is forcefully discarded since there is only one button) the other two places (channel header and server list) won't ever be shown since the alert was already acknowledged.
So, what @larkox is proposing is that this Alert Window should have two buttons, "Ok" meaning like just hiding the window and the "Don't remember again" which will hide the alert icons from the channels header and server lists and won't show the Alert again. We would like to read your thoughts on this. Thanks!
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.
@johndavidlugtu looping you in here for this conversation given it's in the realm of potentially missing notifications due to server configuration (ie push notifications are disabled) and this PR makes some changes to how we are informing end users about that.
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.
ok, understood, will proceed with that change then and update this PR. thanks @johndavidlugtu 👍
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.
hey @esethna @johndavidlugtu the change is now ready and working as expected:
Screen.Recording.2023-10-11.at.11.57.58.mov
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.
hey @johndavidlugtu @esethna friendly reminder on this one :)
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 ping @pvev
Can we update the copy to say "Due to the configuration of this server..."
Otherwise, lgtm!
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.
done @johndavidlugtu
app/screens/home/channel_list/servers/servers_list/server_item/index.ts
Outdated
Show resolved
Hide resolved
app/managers/session_manager.ts
Outdated
@@ -121,6 +121,7 @@ class SessionManager { | |||
WebsocketManager.invalidateClient(serverUrl); | |||
|
|||
if (removeServer) { | |||
await removePushDisabledInServerAcknowledged(createKeyFromServerUrl(serverUrl)); |
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 great for when the server gets removed.. but once a server actually starts sending notifications correctly, we should also remove it. I don't see that logic anywhere in the code.
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 canReceiveNotifications
function is the one that receives the config value and depending on it shows or hides the Alert. It is verified in every place where the notification is shown:
mattermost-mobile/app/screens/home/channel_list/servers/servers_list/server_item/server_item.tsx
Lines 263 to 264 in 7244f95
canReceiveNotifications(server.url, result.canReceiveNotifications as string, intl); | |
loginToServer(theme, server.url, displayName, data.config!, data.license!); |
canReceiveNotifications(serverUrl, result.canReceiveNotifications as string, intl); |
Is this what you are referring to?
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.
Approving, but my concern about the first notification not having a "remind me later" option is still there. If you could verify with product before merging I would appreciate it.
sure @larkox . Thanks! |
c4b6937
to
41ca619
Compare
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.
Good, thanks @pvev
Summary
This PR makes sure to show only once the notification Alert about push notifications being disabled in the server.
Ticket Link
https://mattermost.atlassian.net/browse/MM-50354
Checklist
Device Information
This PR was tested on:
Screenshots
Before:
Screen.Recording.2023-08-09.at.23.21.22.mov
Screen.Recording.2023-08-09.at.23.24.33.mov
After:
Screen.Recording.2023-08-10.at.11.59.35.mov
Screen.Recording.2023-08-09.at.23.06.42.mov
Screen.Recording.2023-08-09.at.23.16.18.mov
Release Note