Persistent Alerts [Paid] 2.7.1

[Digest]

Does not work. Maybe this screenshot will be useful. The test mail with a normal subscription receives only 1 letter, and not more and more. Subscribers are unhappy, and so am I. What did I pay for?

Spoiler: spoiler

 

[Xon]

You have the option "Persistent Alert - User Option" set.

Check the new registration option "Generate new alerts without reading threads", it defaults to "false".

You can bulk opt-in everyone with this SQL:

update xf_user_option
set sv_persistent_alert = 1

 

[Digest]

Check the new registration option "Generate new alerts without reading threads", it defaults to "false".

where is it?

Spoiler: scrinshot

 

[Digest]

You can bulk opt-in everyone with this SQL:
update xf_user_option set sv_persistent_alert = 1

The technician has already done this, as far as I know. All parameters = 1

 

[Xon]

where is it?

Spoiler: scrinshot

View attachment 302031
View attachment 302032

It is under the "user registrations" option

 

[Digest]

It is under the "user registrations" option

Ok, I did it. But this is just the default value.

And if the user says that he does not receive letters, what should he do, how can he set up continuous notifications about new messages?

 

[Xon]

I use this add-on (and this exact same version) heavily on my own sites, and it works as expected.

And if the user says that he does not receive letters, what should he do, how can he set up continuous notifications about new messages?

This add-on respects if someone has the replying user ignored, and just because it sent notifications doesn't mean the email provider will forward it to their inbox.

Please confirm with your own testing (ie not a user complaint) that a thread you watch gets multiple emails without visiting the thread, as this will rule out add-on conflicts which are always a possibility.

 

[Digest]

I use this add-on (and this exact same version) heavily on my own sites, and it works as expected.


This add-on respects if someone has the replying user ignored, and just because it sent notifications doesn't mean the email provider will forward it to their inbox.

Please confirm with your own testing (ie not a user complaint) that a thread you watch gets multiple emails without visiting the thread, as this will rule out add-on conflicts which are always a possibility.

Ok, I've highlighted the successful messages that come to my test mail.ru mail after clicking "track topic" + check the notify without visiting topic box.

But there are people whose letter title is shown differently: “subject + new message”.
And there are those who have not received anything since April 28 (mail.ru)

Spoiler: Scrin

 

[Xon]

Other users may have opt'ed out or depending on how that email tracking log works the email might have bounced and not be reported as sent.

 

[Digest]

They do not refuse, they are unhappy that the letters do not arrive.
And the logs show that the letters were not sent

 

[Xon]

Open a ticket on my site, there may be 3rd party addon conflicts and I will need access to your site (via ssh/sftp) to analyse how the relevant functionality is being extended.

 

[Xon]

Does not work. Maybe this screenshot will be useful. The test mail with a normal subscription receives only 1 letter, and not more and more. Subscribers are unhappy, and so am I. What did I pay for?

Spoiler: spoiler

View attachment 301995

View attachment 301996
View attachment 301997

This appears to be a known compatibility issue with [AL] Core Package - 1.6.4[B].

You must update to [AL] Core Package - 1.7.0 or later

 

[noxa]

I am getting a lot of warning after upgrading to XF v2.2.16 (patch 2)

 

[Xon]

You'll need to update Alert Improvements add-on. (Rebuilding it might be enough)

 

[noxa]

Yeah, that worked.

Thanks!

A weird template caching bug is present in the Alert Improvement plugin. Even if you rebuild the addon, it does not update the addon template code.

The only solution is to disable dev mode and then go for rebuild. Anyways, thanks again as always

 

[Xon]

The only solution is to disable dev mode and then go for rebuild. Anyways, thanks again as always

This is a known XenForo foot-gun.

If you have dev mode enabled, never use the web-installer. Otherwise what happens is if you touch anything which would generate the _output for an add-on it'll only generate a single file and that will have priority over the _data folder. Which makes rebuild/import/etc a time-bomb, as the add-on data is only partially there.

 

[Digital Doctor]

If you have dev mode enabled, never use the web-installer.

is there a way to prevent that situation ? some kind of check ?

 

[Reflect]

Suggestion on alert setting option - globally and at the user level: Create an option to Suppress Emails to Once Daily if there are more new replies to a watched thread.

The thinking is this... if an email alert is sent for every single reply it can get way too overwhelming in your inbox for a busy thread. But if you only get one alert for new replies and then no more alerts after that until you view the thread, you can easily forget or not know that the thread is really active. There should be an option that fits in between these two options. Maybe it can be a daily email notification for a thread if there are consistent new unread replies being posted every day. Or maybe it's a reminder email about threads that still have new replies that are unread. Something to prompt the user to go read the unread replies daily or weekly (or a specified interval), but not a persistent email alert.

I and my membership wholeheartedly agree with Ludachris' comment.

One of the most common complaints on my forum is "I missed the one-and-only notification email and never heard about thread that I was following ever again!".

This is despite perhaps tens, hundreds or thousands of additional posts being made to the thread. My site has a lot of long-running, deep discussions, that can go on for thousands of posts. Being able to follow these threads and them not be forgotten is very important for my members.

I've had a look at the available plugins for XF to manage this problem, and there seems to be nothing in between these two choices:

1. XF default behaviour - Send one email. If there are 1000 additional posts the user will never know about them.
2. This plugin's current behaviour - Send 1000 emails. Risk damaging your email sender reputation and triggering anti-spam mechanisms.

Is there a plugin that allows for a middle ground?

Either of these would be good:

• 3 reminders: If a user has missed a notification about a watched thread, remind them after 1 day, one week, and one month, then stop.
• A "Here's what you missed" email digest: If a user has missed a notification about a watched thread, send them a weekly digest of all the watched threads they were notified about but currently have unread posts

If there are any other plugins out there that could provide either of the above, please let me know. I think they would be great additions to this plugin. My apologies if I have misunderstood how this plugin works. Thank you for listening.

 

[John917]

@Xon Would there be any way we can have "email" as a setting for these notifications? I bought this thinking users will be getting emails on top of the notifications and now I'm stuck.

I must be missing something as it seems like when I bought it, it was because it should be working with emails?

 

[John917]

@Xon Would there be any way we can have "email" as a setting for these notifications? I bought this thinking users will be getting emails on top of the notifications and now I'm stuck.

I must be missing something as it seems like when I bought it, it was because it should be working with emails?
View attachment 306124

Sorry I think I got it. Does "Watched Threads Filtering" work the same and sends emails for every new thread created in a node?

I also noticed something wrong where I have "Persistent Alert Only alert on no unread alerts" off and in the user setting it contradicts and it's unchecked by default where it says "generate new alerts without reading threads."

update it looks like the ACP setting works BUT the user setting being unchecked should be checked (even though it works as if it was checked already). This can be confusing for users looking to turn this off to see that it's already unchecked (when technically it's checked in the backend).