Discourse Push Notifications

official

(Stephen Chung) #179

By the way, if the site setting push_notifications_enabled is NOT true, then you get the following job error:

Job exception: unexpected return

/var/www/discourse/plugins/discourse-push-notifications/plugin.rb:83:in `block (2 levels) in activate!'
/var/www/discourse/lib/discourse_event.rb:12:in `block in trigger'
/usr/local/lib/ruby/2.4.0/set.rb:324:in `each_key'
/usr/local/lib/ruby/2.4.0/set.rb:324:in `each'
/var/www/discourse/lib/discourse_event.rb:11:in `trigger'
/var/www/discourse/app/services/post_alerter.rb:419:in `create_notification'
/var/www/discourse/app/services/post_alerter.rb:537:in `block in notify_post_users'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activerecord-5.1.4/lib/active_record/relation/delegation.rb:39:in `each'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activerecord-5.1.4/lib/active_record/relation/delegation.rb:39:in `each'
/var/www/discourse/app/services/post_alerter.rb:536:in `notify_post_users'
/var/www/discourse/app/services/post_alerter.rb:119:in `after_save_post'
/var/www/discourse/app/services/post_alerter.rb:7:in `post_created'
/var/www/discourse/app/jobs/regular/post_alert.rb:9:in `execute'
/var/www/discourse/app/jobs/base.rb:134:in `block (2 levels) in perform'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/rails_multisite-1.1.0.rc4/lib/rails_multisite/connection_management.rb:71:in `with_connection'
/var/www/discourse/app/jobs/base.rb:129:in `block in perform'
/var/www/discourse/app/jobs/base.rb:125:in `each'
/var/www/discourse/app/jobs/base.rb:125:in `perform'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/processor.rb:188:in `execute_job'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/processor.rb:170:in `block (2 levels) in process'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/middleware/chain.rb:128:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:79:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/middleware/chain.rb:130:in `block in invoke'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/middleware/chain.rb:133:in `invoke'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/processor.rb:169:in `block in process'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/processor.rb:141:in `block (6 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/job_retry.rb:97:in `local'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/processor.rb:140:in `block (5 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq.rb:36:in `block in <module:Sidekiq>'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/processor.rb:136:in `block (4 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/processor.rb:204:in `stats'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/processor.rb:131:in `block (3 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/job_logger.rb:7:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/processor.rb:130:in `block (2 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/job_retry.rb:72:in `global'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/processor.rb:129:in `block in dispatch'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/logging.rb:44:in `with_context'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/logging.rb:38:in `with_job_hash_context'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/processor.rb:128:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/processor.rb:168:in `process'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/processor.rb:85:in `process_one'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/processor.rb:73:in `run'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/util.rb:16:in `watchdog'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/util.rb:25:in `block in safe_thread'

(Sevos) #181

I’ve installed this extension: Discourse Push Notifications

I would like to set these notifications by default - so that it works on every user, including the newly registered ones.

I tried a solution from the last post of topic, but it doesn’t work.

Maybe someone can tell me how I can do this?


(Mukul Dilwaria) #182

Can one explain me how to do these steps. Also i want to enable push notifications for all users


(Stephen Chung) #183

I don’t think you can, at least I haven’t found a way to globally enable push notifications automatically.

The user has to do this manually. The plugin can probably pop up a notice to ask them, but this feature is not in yet.


(Alan Tan) #184

Thanks for reporting. Fixed in


(Sevos) #185

Now the notifications are enabled by default?


(Felix Freiberger) #186

No, push notifications cannot be enabled without user consent.


(Sevos) #187

What? It doesn’t make any sense.

In the case of IPS (commercial forum software) an automatic query is sent to the user whether he wants to enable notifications.

I understand that for you the browser button is “insufficient awareness”?


(Felix Freiberger) #188

Huh? I don’t understand that question.

That confirms what I’m saying: User consent is always required.
If you’re looking for a setting for the plugin that causes Discourse to immediately prompt the user to allow push notifications, I’m pretty sure that this doesn’t exist yet (but would be an interesting addition).


(Sevos) #189

Can’t you add it to your plugin?


(Felix Freiberger) #190

It’s not my plugin, so this is probably a question for @tgxworld :slight_smile:


(Stephen Chung) #191

Well, AFAIK, Discourse does not pop up a message (when push notifications is enabled) asking the user to activate it. The activation button is buried inside the user profile page, which hardly nobody notices.

It will be better, if the user has not decided yet, to do a popup asking the user whether he/she wants to activate push notifications.


(Jeff Wong) #193

This might fit your need:

PR on its way:

This PR also adds a confirmation notification (similar to how slack/discord push a notification) immediately after a user subscribes.


(Steve) #195

Why can’t we mirror the behaviour seen with desktop notifications?

The default appears to be Discourse prompting the user directly to accept desktop notifications via the native dialog on any browser where they aren’t enabled whenever a potential new notification arrives.

Is there anything which prevents us from duplicating that? Surely we should be aiming for parity in the front end?


(Jeff Wong) #196

Tbh I’m not really a fan of the just-in-time ask method for desktop notifications, and that is difficult to replicate with service workers.

Desktop notifications are synchronous - meaning that you can receive something in your main app’s logic, ask for notification permission, and after it’s granted display the notification.

Push notifications come from the chrome/Firefox push service that needs to know your browser accepted the permission to push before it can be sent. These messages can be sent even when your browser window is closed so there may not even be a chance to prompt the user for permission. A user must choose to subscribe to these notifications prior to receiving anything in push notification land.

I’m all for mirroring the behavior of notifications, but I’d suggest we move towards an opt in style as how it’s suggested here with a banner, similar to slack/discord.


(Felix Freiberger) #197

Note: This plugin just received an update that is currently incompatible with the beta channel. If you’re on the beta train like me, you’ll have to wait for the next beta to be released before the plugin will be compatible again.

(It’d be really nice if we could prevent issues like this…)


(Alan Tan) #198

Ah yes. The work around now is to lock the plugin against an older commit.


(Jeff Wong) #199

Wondering if it would be worth it to add some kind of tracking branch logic for plugins to account for this, and have a “beta” branch that points to an older commit on a plugin’s master branch.


(Erlend Sogge Heggen) #200

It’s been discussed here: Compatibility checks and stable versioning for plugins

Feel free to add any additional thoughts you may have.


(Burke) #201

Ack! We’re on the beta of Discourse. I was catching up on updates and ran into an error when updating this push notifications plugin.

discourse-push-notifications/gems/2.4.2 --no-document --ignore-dependencies
rake aborted!
NoMethodError: undefined method `register_service_worker' for #<Plugin::Instance:0x00007fbf61648ea8>
Did you mean?  register_emoji
/var/www/discourse/plugins/discourse-push-notifications/plugin.rb:12:in `activate!'

Are there some tips posted somewhere on how to rollback a plugin update and lock the plugin against an older commit? I’ve done some searching here + googling and haven’t found anything yet.

Thanks!