Notification banners ignore the "Do not disturb" user status

[vladopol]

Steps to reproduce

1. Set the user status to Do not disturb.
2. Receive a message in any conversation.

Expected behaviour

No notification banner, like in the web client, which hides browser notifications while
the status is dnd.

Actual behaviour

A banner pops up for every message. Only the sound and the call popup honour the
status. There is also no way to turn the banner off by hand: setting Show call
notification popup to Never just replaces the popup with a plain banner.

Cause

In src/talk/renderer/notifications/notifications.store.js,
showNativeNotification() looks at the user status only for the sound
(shouldPlaySoundChat) and for the call popup (enableCallbox) - the
new Notification(...) branch is not gated. The DND check in Push.php never applies
here, since the client polls instead of receiving push.

Suggested fix

Two more settings, following the scheme #632 established for the sound:
showNotificationChat and showNotificationCall, each always | respect-dnd | never,
defaulting to respect-dnd. Keeping calls separate preserves the current option of a
plain banner instead of the callbox window (enableCallbox: never +
showNotificationCall: always).

Versions

• Nextcloud Talk Desktop 2.2.3 (built-in Talk 24.0.3), macOS
• Nextcloud 34.0.1, Talk 24.0.2

[vladopol]

Thanks for the triage, but I do not think #1801 covers this report.

#1801 is about the desktop environment's own switch — org.gnome.desktop.notifications show-banners on GNOME — where the OS suppresses notifications for every application. This report is about the Nextcloud user status dnd, which is server-side and platform-independent.

The rest of the product already honours that status: the web client gates browser notifications on this.userStatus !== 'dnd' (notifications/src/NotificationsApp.vue, showBrowserNotifications), and push is dropped for non-priority notifications in notifications/lib/Push.php. The desktop client polls the OCS endpoint itself and shows a banner regardless.

The two do not overlap: with #1801 implemented, a user on macOS or Windows who sets their status to "Do not disturb" would still get a banner for every message.

In the desktop client the status is consulted only for the notification sound and for the callbox. When it suppresses the callbox, showNativeNotification() falls through to new Notification(...) — so an incoming call is downgraded to a banner rather than silenced.

Separately, I came across #1152, which is much closer to this report. It uses the same signal (userStatusStore.isDnd), and its approach looks simpler than adding per-notification settings: the callbox config becomes a boolean and the status is always respected. Applying that same rule to the banner branch would cover this report as well.

Could this be reopened? I have an implementation running in production and would be glad to open a PR along the lines of #1152 if that is useful.