phpBB • Free and Open Source Forum Software

Several people have reported an issue with this in the support forum but no matter how many times I tell them it's a bug no one ever submits a ticket. I guess it's up to me.

Configuration is admin activation and queue is enabled

Scenario 1 (where it works correctly): user registers and immediately receives welcome email stating that their account is currently inactive and they will get an email once an admin activates the account. The admin immediately gets the email and activates via the email link - > ucp.php?mode=activate and the user immediately gets the email notification that their account has been activated. All this works correctly and consistently b/c the emails bypass the queue.

Scenario 2 (which doesn't work correctly): user registers and immediately receives welcome email stating that their account is currently inactive and they will get an email once an admin activates the account. The admin immediately gets the email but instead activates the user via the ACP by selecting Users & Groups -> Inactive users -> marking the username in the list view (the check box) and selecting Activate. The activation notification email to the user is generated but sent to the queue instead of sent immediately like scenario 1, inconsistent and incorrect behavior. The activation notification email needs to bypass the queue just like it does in scenario 1 and scenario 3.

Scenario 3 (which now works in the latest SVN - 10118 but is broken in 3.0.5): user registers and immediately receives welcome email stating that their account is currently inactive and they will get an email once an admin activates the account. The admin immediately gets the email and activates the account in the ACP by selecting Users & Groups -> Inactive users -> selecting the user and bringing up the Overview form and using the Quick tools -> Activate account. The activation notification email is generated and immediately sent, bypassing the queue. Just an FYI...in 3.0.5 this 3rd method of activation does not generate any email notification at all. I am not sure which rev fixed that bug

Summary: All three methods of activating a user account should generate the same behavior/result, an immediate notification that bypasses the queue.

Scenario 2, the one you're pointing out as being the issue, requires the queue in the case that an admin decides to activate multiple accounts at the same time. If the admin decides to say activate the entire list of inactive accounts that might get him into trouble with his/her ISP or some of them might not get sent (emailer function error). Scenarios 1 and 3 are obviously different and shouldn't need the queue.

What exactly is the "bug" you're pointing out? That the email doesn't get sent immediately because it gets sent to the message queue whereas in the other 2 cases it does? Or that the email is not received at all?

DavidIQ wrote:Scenario 2, the one you're pointing out as being the issue, requires the queue in the case that an admin decides to activate multiple accounts at the same time. If the admin decides to say activate the entire list of inactive accounts that might get him into trouble with his/her ISP or some of them might not get sent (emailer function error). Scenarios 1 and 3 are obviously different and shouldn't need the queue.

Sorry but that argument doesn't really hold up. An admin can also choose to activate the same # of accounts one right after the other from the emails, or also activate an entire list of users one right after the other using the Quick tools activate, (methods 1 & 3) so why does the same action of activating and sending the same # of emails deserve different treatment based on what GUI they use to do it? The bottom line is that activation notifications need to behave consistently else you get what you see in support on a regular basis of users reporting that their boards are broken and not sending activation emails. For the last few months I've had to tell people to disable the queue entirely, is that what you want to continue? Fine with me I'm happy to keep pointing out the inconsistencies to the users. ;-)

Speaking of inconsistencies i want to point out that it should not matter if the queue is used or not - it *does* matter for boards having no visits though, because here the send out of the queued emails would not be triggered. But usually the difference is only a few minutes.

That said, it is not a bug that the queue is used - if people have problems with emails within the queue this should be investigated and fixed, and not trying to fix the symptoms or circumvent broken things.

Acyd Burn wrote:Speaking of inconsistencies i want to point out that it should not matter if the queue is used or not - it *does* matter for boards having no visits though, because here the send out of the queued emails would not be triggered. But usually the difference is only a few minutes.

But it does matter or else there would not be the # of support topics that are directly related to this issue. Currently I advise them to disable the queue or wait it out, they overwhelmingly choose to disable the queue. They shouldn't have to is my point.

Acyd Burn wrote:That said, it is not a bug that the queue is used - if people have problems with emails within the queue this should be investigated and fixed, and not trying to fix the symptoms or circumvent broken things.

We are talking about admin activation here remember, how many boards setup to admin activate do you truly believe are going to mass activate on the scale you are assuming that it would be a problem for their MTA? If you look at the support forum and the topics surrounding this you will see that the majority of users who are using admin activate are doing so one off or in small batches because the whole point of admin activate is to get a closer look at the registrant before they are activated. I think the # of admins who are going to ever try and activate pages of inactive users is a very small minority of the user base and yet that is what you have coded the behavior to. A better compromise would have been to provide a 'Send to queue' toggle similar to the mass email function of 'Send immediately'. The "bug" is really the fact that the same function (admin activation) generates inconsistent behavior depending on how you trigger it, which leads the user to believe their board is somehow broken. Not to mention that registration emails and activation emails should have a natural higher priority than emails like subscriptions or PM notifications, lending additional support that they by default should bypass the queue if enabled. A user should not have to disable the queue to make sure the registration process completes in a timely manner.

Looking at the code Scenario 2 always did not use the queue. The only location for the welcome messages was acp_inactive (the list of inactive users).

edit: sorry, misread Users & Groups -> Inactive Users. Thought the users profile was meant.

I still have this problem on 3.0.5. Is there a fix for this? I am reluctant to upgrade to 3.0.6 because of the bugs there and I'm not even sure that this was addressed in 3.0.6.

I've tried playing with the queue #'s, mail function (site vs smtp), etc. My host supports everything, so its not that. What is going on!? I've had this problem for over a year.