New user and registration confirmation

[TonyG]

v2.0.9
A new member registers and gets back a notice that the registration is being considered.
The admin gets an email that a new member requires approval.
The member is approved.
No email is received by the new member.

I realized that the sending of email depends on where the admin goes to do the approval. In the email to the admin we get a link for action=profile. In the new profile we see "Account is not approved" and there is a link to "(approve)". If we click that link, no email is sent. However, if we click the link for "action=admin;area=viewmembers;sa=browse;type=approve" we get to the Awaiting Approval list where we can select requests and "Approve and send email".

So some members won't get an email depending on which link the admin clicked from their email confirmation.

I'll propose the following related enhancements, and I'm wondering if this is something that can or is addressed by mods:
1) Add an option to the options page which disables the admin=profile link in the admin notification. This forces the admin to go to the page and to select the proper approval operation.
2) Add an option to the options page which forces an email confirmation for all approval/rejection operations. This way all approvals and all rejections can get the same behavior without any accidental deviance from site policy.
3) Add an option which forces the Require Activation for all new users. Again this enforces site policy and avoids mistakes.

If this isn't added to the core, there's a hook for integrate_activate in ManageMembers.php, AdminApprove(). I'm thinking that hook and others like it might be used to check for a default option rather than relying on the $_POST['todo'] operation specified by the dropdown list. (Note there are no hooks around rejections or for approve+activate.

Thanks for your consideration.

[Arantor]

So if you always use the admin panel like most people, you can always ensure emails are sent

I would most strongly veto 'yet more configurable things'. More options = more complexity = harder to test = harder to use. I'd rather just remove the link from the profile page.

Or, I'd provide two links, one that sends the email, one that doesn't.

As far as integrate_activate goes, it's primarily for notifying external things of the new activation, though yes you could abuse scoping to change $_POST['todo'] to 'okemail' rather than 'ok'.

[TonyG]

I was thinking about a scenario where there is an admin who is familiar with the details, and other mods who monitor the membership. In this case people need to be educated about what to do, and not. Anyone can make a mistake and just click the wrong link or not set that dropdown. The result is that a new member doesn't get confirmation and may never come back, either forgetting about the site or thinking the membership was rejected. My immediate solution will be to eliminate the profile link from the mod notices, and to advise mods to be careful to always select the right dropdown.

I wasn't talking about abusing scoping but eliminating the dropdown and the 'todo' handling when defaults are specified.

I know there's a bug tracker for SMF but I don't know if that's used for enhancement proposals. If that's a better place for ideas to be put up and shot down I post suggestions like this there from now on. If this forum is the only place for suggestions, I'll stick to reporting problems.

Thanks.

[Arantor]

Anyone can make a mistake and just click the wrong link or not set that dropdown

There has to be a limit on how far you go to prevent users 'doing the wrong thing'.

I wasn't talking about abusing scoping but eliminating the dropdown and the 'todo' handling when defaults are specified.

I know you weren't. I was talking about abusing variable scope to achieve the same end through a hook not specifically designed for the purpose you're trying to use it for, because abusing variable scope allows you to alter the thing that controls behaviour.


I'd suggest Feature Requests as the proper venue for now, with stuff that's relatively certain and/or decided upon getting moved to Github. But note that 2.0 is not receiving any feature development of any kind (and hasn't in 3 years since it went stable)