Lack of interest Please introduce config option "enablePush" (like "enableMail")

[Steffen]

This would make it possible to reliably disable push notifications in development environments by setting $config['enablePush'] = false; in config.php.

 

[Chris D]

You already can “reliably disable” push notifications by disabling the option so if that’s not sufficient then we’ll need some context.

I don’t see the point in having a boolean switch when one already exists.

 

[DragonByte Tech]

Could it be possible that some notifications are sent to users in the time it takes an administrator to login to their freshly duplicated test board, navigate to the options page, clicking the correct sub-category and turning the option off?

If that's unlikely enough to effectively never happen then that's fine, but if there is a chance then it might be worth having a config.php switch just to avoid leaking test installation URLs and getting questions from confused users.

Of course, I could be wrong and push notifications won't ever be sent from this duplicated test board because of different URLs triggering the need to re-enable push on the user's end


Fillip

 

[Steffen]

I regularly sync our database to my development environment (not the whole database but a small subset with only the most recent threads, not all users but only team members etc). I don't want anyone (not even team members) to receive push notifications for stuff I do in my development environment (test replies/quotes/…). Having an "enablePush" option in config.php would reliably eliminate this issue because in config.php I can conditionally set "enablePush" (and "enableMail") depending on environment variables (which, unlike a setting in the database, won't be reset when syncing the database).

That being said, I can tell my database sync script to skip syncing the "xf_user_push_subscription" table. That would solve the problem assuming that I'll never ever import the whole database into a test installation... That doesn't feel very safe, to be honest. I'd probably implement some kind of safeguard like this myself if others don't think it's necessary.

@DragonByte Tech A duplicated test board will send push notifications to your real users. The push services (which are operated by browser vendors) don't care who submits a push notification as long as it is sent to the proper endpoint and has been encrypted + signed with the proper VAPID key. And the VAPID key as well as the endpoints are stored in your database.

 

[markus68]

Yuck, just forgot to manually unselect this in options when I copied my database to my test-site.
I always re-use my config.php in test, so I would really love to have that option to disable pushs

 

[Paul B]

Could it be possible that some notifications are sent to users in the time it takes an administrator to login to their freshly duplicated test board, navigate to the options page, clicking the correct sub-category and turning the option off?

You can edit the src/config.php file to disable it.

I have custom config.php files created for my test/dev installations to disable/set certain things (URL, canonical setting, etc.).

 $c->extend('options', function(\ArrayObject $options)
{
    $options->enablePush = false;
    return $options;
});

 

[markus68]

Thanks Brogan,
I also found that code-snipped from ChrisD and use it successfully now.

Nevertheless I'd vote for such an option and have that also mentioned in the docs alongside the disable-email.

I started doing migration-tests from my 2.1 and really did not expect that 2.1 started sending out these pushes (until I got informed by users on my active board ...) I used to do heavy work on my 2.0 site while migrating from VB and all I had set for a quiet test-installation was email-disable ...

Thanks,
-Markus

 

[Steffen]

The code-snippet doesn't just disable sending push notifications. Instead, it completely disables the push notifications feature. So stuff like the user profile settings and the nag notice at the bottom are gone, too. That's okay but ideally I'd want to keep those things in a development environment.

Similar to $config['enableMail'] (which doesn't disable all email-related UI either, it just skips the actual sending of emails) the proposed $config['enablePush'] should just affect sending push notifications (i.e. it should only be checked in PushNotification::sendNotifications).