We have a YAF forum on our site. We have a forum dedicated to "Announcements" for users to subscribe to. So when we post there, all users get an email notification. But we're finding if they don't visit the site (while logged in) then they won't get further announcements.

I can understand only wanting 1 email for all replies in a thread or forum as default behavior (so you don't get 20 emails for 20 posts). But in this case, since it's an Announcement forum, we want to override that behavior and always have the user get an email, given we won't be posting them that often. How can we do that?

Emma,

If I understand your issue being you want all of your users to receive notifications of new posts to your Announcements Forum, they need to be "watching" the forum. That information is recorded in the SQL Table yaf_WatchForum (screenshot attached.) So if they're entered in this table they should receive notifications independent of whether they visit the site or not.

Good luck,
Dave

I'm afraid that's incorrect... at least for us. The yaf_WatchForum is indeed getting populated if a user clicks the "Watch Forum" button. And like I said, the next time a post is made in that forum, the user does get an email alert. However, unless they visit that forum (while logged in) then they do NOT get any more email notifications when a new post is made in that forum.

If you are saying it work for you, then you must have a different setting enabled that we do not. Can you tell us what it is?

However, unless they visit that forum (while logged in) then they do NOT get any more email notifications when a new post is made in that forum. If you are saying it work for you, then you must have a different setting enabled that we do not. Can you tell us what it is?

I'm sorry Emma. There should be no other setting required. Not that I'm aware of. Did you say you're using YAF 1.9.6.1? Mail is sent out with a background task, with notifications stored first in YAF_MAIL. You may want to confirm data for all subscribers is getting there. Is it a very large number of subscribers? If so, .NET background tasks regardless how well designed, are not the best solution for handling large amounts of SMTP processes.

That's all academic, since you're saying users are somehow dropped from the subscription list (yaf_watchforum?) if they don't visit the site for some period of time. You're saying that they DO receive updates initially, correct?

You're fortunate that Squirrel and Jaben are apparently following this thread, so if I'm giving you bad information you can be confident they can correct me...or provide something I'm missing.

Good luck,
Dave

I did not set up our YAF forum, so I didn't think about checking versions. Upon doing so, I see we're at 1.9.5 RC1, so it's not up to date. If the latest version behaves as you describe, then we'll try to update. Does anyone happen to know if the version we have performed in the manner I'm describing? (Otherwise, upgrading may change nothing if this is an ongoing bug/feature.)

I did not set up our YAF forum, so I didn't think about checking versions. Upon doing so, I see we're at 1.9.5 RC1, so it's not up to date. If the latest version behaves as you describe, then we'll try to update. Does anyone happen to know if the version we have performed in the manner I'm describing? (Otherwise, upgrading may change nothing if this is an ongoing bug/feature.)

Emma,

I personally don't know of any 1.9.5 RC1 issues causing this behavior, but its notification logic is the same as the current release. Perhaps someone else knows about 1.9.5 RC1 notification issues associated with member site activity.

Good luck,
Dave

Thanks for your input, Dave. Just to be certain, could you double-check that your forum works differently than mine? Have User1 subscribe to a forum, and then have User2 post a new thread in it. Assuming User1 gets the email, do not click on the email link to visit the forum site. (In fact, no need to even open the email.)

Now have User2 post another thread in that forum. If what you say is true, then User1 will get a second email, whereas ours does not. If that's the case, then I'm at a loss, unless the older forum version is the problem.

Thanks again.

This issue is likely related to the following post:
http://forum.yetanotherf...email-notifications.aspx 

I am also having the same problem.

(as a side note)
Daily digests also are not working for me which was reported previously, was anything every committed to fix the digest send in 1.9.6.1?

There was an SQL change in the 1.9.6.2 beta code that changed how some of the notifications are handled by the background task. The SQL change can be applied to an older YAF forum. I've seen it tested back to v1.9.5.5 but not sure if it will apply to 1.9.5 RC1 -- I will see if I can find the SQL update on the forums and link to it.

Additionally: If you are seeing delayed notifications - this can be caused by YAF's application pool being timed out and shutdown (from forum inactivity). 99% of your web hosting providers set a very low idle time for IIS application pools. Anywhere between 5 and 20 minutes. If IIS shuts down your application pool, background tasks will also stop and will not restart until the application is restarted (such as a visit to the site triggering IIS to reload the application). Then when the application restarts, any scheduled tasks will resume. Generally, you cannot alter your IIS app pool idle times unless you are on a VPS or dedicated server where you are in control of the IIS configuration.

Other symptoms of application pool timeouts can include being logged out while attempting to post (if you take a long time to compose your message). That error can be resolved by adding a set of machine and decryption keys to your YAF web.config - but this will NOT resolve the app pool from shutting down. It only provides a means for the application to 'remember' its encryption settings for the user cookie and forms validation instead of re-generating them during a restart.

---

http://forum.yetanotherf...on-emails.aspx#post54755 

This is the topic linked directly to Jaben's post with the new SQL code and instructions based on what forum version you are running. v1.9.6.2 is on the horizon - many bugfixes are already in the code, some relating to Daily Digest as well as other email issues (and new logging features for helping diagnose email issues). I'm sure an official packaged beta will be coming soon. In the meantime, the above SQL updates MIGHT help with your notification issues.

DUE TO A QUOTING ISSUE I have re-attached Jaben's complete SQL instructions here:

Please run these SQL changes (they can be run in the Admin->Run SQL Query area).

If you have v1.9.6 or greater, you need to run the following SQL:

ALTER PROCEDURE [{databaseOwner}].[{objectQualifier}mail_list]
(
	@ProcessID int,
	@UTCTIMESTAMP datetime
)
AS
BEGIN
	BEGIN TRANSACTION TRANSUPDATEMAIL
		UPDATE [{databaseOwner}].[{objectQualifier}Mail]
		SET 
			ProcessID = NULL
		WHERE
			ProcessID IS NOT NULL AND SendAttempt > @UTCTIMESTAMP

		UPDATE [{databaseOwner}].[{objectQualifier}Mail]
		SET 
			SendTries = SendTries + 1,
			SendAttempt = DATEADD(n,5,@UTCTIMESTAMP),
			ProcessID = @ProcessID
		WHERE
			MailID IN (SELECT TOP 10 MailID FROM [{databaseOwner}].[{objectQualifier}Mail] WHERE SendAttempt < @UTCTIMESTAMP OR SendAttempt IS NULL ORDER BY SendAttempt, Created)
	COMMIT TRANSACTION TRANSUPDATEMAIL

	-- now select all mail reserved for this process...
	SELECT TOP 10 * FROM [{databaseOwner}].[{objectQualifier}Mail] WHERE ProcessID = @ProcessID ORDER BY SendAttempt, Created desc
END

For v1.9.5.x, please use the following SQL:

ALTER PROCEDURE [{databaseOwner}].[{objectQualifier}mail_list]
(
	@ProcessID int
)
AS
BEGIN
	DECLARE @UTCTIMESTAMP datetime
	
	SET @UTCTIMESTAMP = GETUTCDATE()
	
	BEGIN TRANSACTION TRANSUPDATEMAIL
		UPDATE [{databaseOwner}].[{objectQualifier}Mail]
		SET 
			ProcessID = NULL
		WHERE
			ProcessID IS NOT NULL AND SendAttempt > @UTCTIMESTAMP

		UPDATE [{databaseOwner}].[{objectQualifier}Mail]
		SET 
			SendTries = SendTries + 1,
			SendAttempt = DATEADD(n,5,@UTCTIMESTAMP),
			ProcessID = @ProcessID
		WHERE
			MailID IN (SELECT TOP 10 MailID FROM [{databaseOwner}].[{objectQualifier}Mail] WHERE SendAttempt < @UTCTIMESTAMP OR SendAttempt IS NULL ORDER BY SendAttempt, Created)
	COMMIT TRANSACTION TRANSUPDATEMAIL

	-- now select all mail reserved for this process...
	SELECT TOP 10 * FROM [{databaseOwner}].[{objectQualifier}Mail] WHERE ProcessID = @ProcessID ORDER BY SendAttempt, Created desc	
END

---

Thanks for the SQL update, I'll try processing that shortly....

How far on the horizon is 1.9.6.2? The digests are of great interest to me as well if they are working correctly. Is there a 1.9.6.2 beta or is it still under strict development?

Thanks for the SQL update, I'll try processing that shortly....

How far on the horizon is 1.9.6.2? The digests are of great interest to me as well if they are working correctly. Is there a 1.9.6.2 beta or is it still under strict development?

At any time, you can pull a copy of the source code and compile it yourself, but keep in mind - the source is a 'snapshot' of the current programmed state of YAF. It is NOT recommended for production server by any means - due to the fact that there can be unfinished segments of the code at any time. Additionally, bugs that are found in source versions get addressed as developers have time during that release cycle - so if you do find a problem, developers can not promise a fix or a time for that fix. You would have to wait until something is available.

On the flip side of that, if you do pull, compile, and run a source version, it is highly appreciated if you do lodge bug reports or issues here on the support forums or on the BugTracker so that developers do know of the problem and can address it. It's just not recommended to run a source version on a production server because if there is a problem, your forum could be in-accessible until a fix is made available - so downtime could be a problem.

Unfortunately, developers are not able to provide an update release schedule, due primarily to YAF being a community developed project, so speed of development depends entirely on developer availability. I try to provide forum support so the developers have more time to concentrate on code while I handle many of the simpler problems YAF users and admins might encounter.

At this time, I have a source version running on one of my production users, but we do not utilize the digest feature, so I cannot comment on it's availability, stability, or function. I do anticipate bringing another development server online where I can test features like that and help in tracking and development.

---

Unfortunately that sql update didn't work for me, email notifications are still not going out. Any other suggestions? I may just try the current build...

Unfortunately that sql update didn't work for me, email notifications are still not going out. Any other suggestions? I may just try the current build...

Is your forum able to send mail at all? There are a couple settings in the Host configuration menu that have to do with notifications, but I believe they relate to the Private Message notifications --

A good way to test email configuration is if you have 'Email Verification Required' enabled in your host configuration, and do a 'test' registration to see if the mails are going out or not --

---

on YAF 1.9.6.1 (Date: 3/18/2012). DNN
my mails do get sent when i try a test Digest or Email .. but the notifications are not being sent to anyway . while searching i couldnt even find the mail.config and app.config etc

Pointers?