Very likely I’m missing a simple connection point in thinking through this, but I’m a bit unclear on what the notifications array in config.js does and how to use it. Does uncommenting a line in the array (and the array itself) make the specific notification explicitly active (while others assume inactive status)? Or does uncommenting and setting a value of ‘false’ disable the specific notification? How does this work?
As far as I can tell, if you don’t set the ‘notifications’ config then no filtering happens and notifications show up as usual; if you do set that config, that it acts as a whitelist i.e. you need to include the title/description of all the notifications you wish to allow in the array.
This does make maintenance a little unwieldy if your goal is to simply filter out a small number of notifications since you’ll need to manually keep that list up-to-date across upgrades when new notifications are added.
Disclaimer: I haven’t actually tested this out myself. Inferred based on source below.
Right, that was my thinking too, but on testing, it didn’t quite seem to work that way. My expectation was that once enabled, it automatically disables (or overrides) the default behavior - which is to allow all those notifications. So, in essence, only the notifications explicitly enabled in the array (whitelisted) should show up. This wasn’t my experience though.
Ultimately, my goal is to remove some notifications. Notifications about server errors for instance, I don’t think should be shown to users besides the host (e.g. recording failed, recording busy e.t.c…). So, if I can disable those notifications (hopefully for users, but still preserve them for the host), that would be awesome.
Maintaining the list shouldn’t be much of a hassle since config.js survives upgrades. If/when new notifications are introduced, enabling them would be a breeze.
Just did a quick unscientific test and it did do what I hoped it would:
notifications = ['notify.raisedHand'], I get notifications for raised hands but not when I’m kicked out
notifications = ['notify.raisedHand', 'dialog.kickTitle'], I get notifications when kicked or when someone raises their hand.
notifications = ['dialog.kickTitle'], I get notification when kicked but not for raised hands.
notifications = false, I’m back to getting all notifications
Was there a specific notification that wasn’t filtered out (or allowed through) as you expected?
That would be nice indeed.
Enabling would be easy if you know what to enabled. Not sure if everyone has a process for reconciling config changes between updates.
But I agree; it’s no biggie. Just floating the idea that it could be something that could catch someone unaware and they lose out on newly introduced notifications. The inverse would be equally problematic I suppose – If I had painstakingly declared only notifications I care about, I wouldn’t want an update to suddenly pop in a new one so in this case whitelisting works well.
I use the following to disable all notifications
To do the same thing using meeting link
Ah, see… that was the logical knot for me. I actually did set it correctly, but was looking for the wrong thing (I only allowed a recording notification and then was surprised recording notification showed up when I activated recording ). Brain-freeze moment. Yeah, it does work as expected.
I wish there was a way to restrict certain notifications for users only though, while the moderator still sees them.
This is good. I actually never considered the option. Seeing a bunch of notifications pop up during a meeting can be distracting. I previously just shortened their lifespan and set them to autodismiss, but preventing them altogether is probably a smoother option.