When users receive a PM, the taskbar icon shows a red indicator. Same indicator for when a user is mentioned, either directly, or via a group mention like @here, @all, etc.
However, when they receive a PM in a multi-user PM, they only see a blue indicator.
Is this intentional behavior?
We’ve had few reports on this before but we’ve been unable to reproduce this on our end. Would you be able to help share any other details about reproduction steps and/or your environment?
Certainly! Reproduction steps are straightforward:
Environment:
We’re running https://github.com/mattermost/mattermost-docker/, latest version (5.23.1). We use the Postgres DB, default app. We do not use the web container, but run our own nginx proxy. Configs are below.
docker-compose.yml
version: "3"
services:
db:
build: db
read_only: true
restart: unless-stopped
volumes:
- ./volumes/db/var/lib/postgresql/data:/var/lib/postgresql/data
- /etc/localtime:/etc/localtime:ro
environment:
- POSTGRES_USER=mmuser
- POSTGRES_PASSWORD={REDACTED}
- POSTGRES_DB=mattermost
app:
build: app
ports:
- "8000:8000"
restart: unless-stopped
volumes:
- ./volumes/app/mattermost/config:/mattermost/config:rw
- ./volumes/app/mattermost/data:/mattermost/data:rw
- ./volumes/app/mattermost/logs:/mattermost/logs:rw
- ./volumes/app/mattermost/plugins:/mattermost/plugins:rw
- ./volumes/app/mattermost/client-plugins:/mattermost/client/plugins:rw
- /etc/localtime:/etc/localtime:ro
# When you want to use SSO with GitLab, you have to add the cert pki chain of GitLab inside Alpine
# to avoid Token request failed: certificate signed by unknown authority (link: https://github.com/mattermost/mattermost-server/issues/13059)
# - <path_to_your_gitlab_pki>/pki_chain.pem:/etc/ssl/certs/pki_chain.pem:ro
environment:
# set same as db credentials and dbname
- MM_USERNAME=mmuser
- MM_PASSWORD={REDACTED}
- MM_DBNAME=mattermost
- MM_SQLSETTINGS_DATASOURCE=postgres://mmuser:{REDACTED}@db:5432/mattermost?sslmode=disable&connect_timeout=10
# The web container is unused. See /etc/nginx/sites-available/mattermost for web proxy config
# web:
# build: web
# ports:
# - "80:80"
# - "443:443"
# read_only: true
# restart: unless-stopped
# volumes:
# # This directory must have cert files if you want to enable SSL
# - ./volumes/web/cert:/cert:ro
# - /etc/localtime:/etc/localtime:ro
# # Uncomment for SSL
# # environment:
# # - MATTERMOST_ENABLE_SSL=true
nginx
upstream backend {
server localhost:8000;
keepalive 32;
}
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=mattermost_cache:10m max_size=3g inactive=120m use_temp_path=off;
server {
if ($host = {MATTERMOST_URL_REDACTED}) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80 default_server;
server_name {MATTERMOST_URL_REDACTED};
}
server {
listen 443 ssl http2;
server_name {MATTERMOST_URL_REDACTED};
ssl on;
ssl_certificate /etc/letsencrypt/live/{MATTERMOST_URL_REDACTED}/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/{MATTERMOST_URL_REDACTED}/privkey.pem; # managed by Certbot
ssl_session_timeout 1d;
ssl_protocols TLSv1.2;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SH$
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:50m;
ssl_dhparam /etc/nginx/certs/dhparam.pem;
add_header Strict-Transport-Security 'max-age=31536000';
location ~ /api/v[0-9]+/(users/)?websocket$ {
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
client_max_body_size 50M;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Frame-Options SAMEORIGIN;
proxy_buffers 256 16k;
proxy_buffer_size 16k;
client_body_timeout 60;
send_timeout 300;
lingering_timeout 5;
proxy_connect_timeout 90;
proxy_send_timeout 300;
proxy_read_timeout 90s;
proxy_pass http://backend;
}
location / {
client_max_body_size 50M;
proxy_set_header Connection "";
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Frame-Options SAMEORIGIN;
proxy_buffers 256 16k;
proxy_buffer_size 16k;
proxy_read_timeout 600s;
proxy_cache mattermost_cache;
proxy_cache_revalidate on;
proxy_cache_min_uses 2;
proxy_cache_use_stale timeout;
proxy_cache_lock on;
proxy_http_version 1.1;
proxy_pass http://backend;
}
}
Any other details you need?
Are you on Mac? If yes, what are your Mac system notification setting set to for Mattermost?
I am not on a Mac, no. I’m on Windows, using the desktop (Electron) client. Screenshots in the OP are from my system.
Chatting with two of my colleagues who’ve also seen the issue, one is on Windows and the other is on MacOS. Both use Mattermost in the browser. Both use Chrome as their standard browser. My colleague using MacOS has also reproduced it in Firefox when using that.
Thanks, what do the OS notification settings look like for Mattermost?
Need anything further here Amy? Any luck with reproduction? To rule out any local environment issues, I tested this on demo.mattermost.com, and encountered the same issue - blue notification icon instead of red.
I asked our desktop app team and they didn’t have ideas on this. I’ll next escalate this to our general R&D team and see if anyone else could help take a look.
@amy.blais, could this be because group messages don’t count as mentions in the same way as a direct messages do? I seem to recall a planned change in this regards to make group messages behave like direct messages as such.
