I confirm this
Message obtained by user when created account:

Mail received by user

Message displayed on site to user after confirmation

Mail received by admin

Message seen by admin on site after activating through the link received in mail above

This is an important REGRESSION.
could be related to
f7754e7

It could be related but only in so far as that fixed a bug where if the admin was logged in they couldn't activate the user. They had to be logged out to activate the user from the email.

I can confirm this behaviour, but am under the impression that I had it under 3.3.3 as well. Not sure though.
An issue maybe related is that I get multiple notifications to the admin. I'm going to debug this tonight and will post my findings.
I am not that familiar with the rules and customs of this community, so if I post in the wron play or way, gentle hints are much appreciated.
H

Just tested. Same behaviour on 3.3.3. New user clicks on activation link, gets the message above. Admin gets 4 (!) notifications (identical), after activation in the BE no message to user.

The multiple admin mails were my mistake. All good there.

In component/com_users/models/registration.php line 74 and following this:

        // Permissions check for admin to activate user
        $admin = JFactory::getUser();
        $allow  = $admin->authorise('core.edit.state', 'com_users');

returns the user just registered for the $admin and a false for $allow. Consequently in line 146

        elseif (($userParams->get('useractivation') == 2) && $user->getParam('activate', 0) && $allow)

the condition is false. No mail is sent.

The user is still activated because the if - elseif - else ends with line 180 and following:

        else
        {
            $user->set('activation', '');
            $user->set('block', '0');
        }

Any idea why the JFactory::getUser() returns the wrong user?

Henrik

Do I understand the process correctly?
1. User registers. A token is generated and stored in the db. Also a mail with an activation link containing this token is sent to the user.
2. User clicks on the link. As admin activation is on, the account is not activated, but instead a new different token is generated, stored with the user in the db and sent as part of a new activation link to the admins. The parameter activate of the user object is set to 1 to reflect that the user verified the registration by clicking on the link.
3. Anyone who has the new link, logged in or not, should be able to use it to activate the user. As activate=1 is set, the user is activated.

If this is so, why use the code in line 74 at all? Why check for authorization? There won't be any as long as one is not logged in. So the fix f7754e7 actually made things worse???

Sorry HAZET, but 3.3.3 is working as expected. I'm not a coder but this definitely happened after updaten to 3.3.4.
Joomla 3.3.3:
User registers:

User receives e-mail with verification link. User clicks link.

Admin receives e-mail with activation link and clicks link:

User receives e-mail that account has been confirmed.

Dear Madam, dear Sir,

The intended recipient of your mail, Henrik Zawischa, is no longer with SONIC Performance Support. Your mail may be forwarded and read by a colleague, who will contact you if appropriate.

Kind regards

SONIC Performance Support

Confirm that registration with admin approval works as expected in J333. Also confirm findings about j334. It requires administrator to be logged in on frontend for sending mail to user and receiving correct message.
Also confirm checking administrator permissions is poorly implemented(adding condition && $allow on line.146). Even when it is desirable!

Ok so what's the best solution. Because before previous PR we have the
opposite issue where if the admin is logged in then no activation OR email
happens!

(Apologies if this seems terse - on phone so keeping it short)

On Sunday, September 28, 2014, sovainfo notifications@github.com wrote:

Confirm that registration with admin approval works as expected in J333.
Also confirm findings about j334. It requires administrator to be logged in
on frontend for sending mail to user and receiving correct message.
Also confirm checking administrator permissions is poorly
implemented(adding condition && $allow on line.146). Even when it is
desirable!

—
Reply to this email directly or view it on GitHub
#4376 (comment).

Suggest to replace the if .....else structure with a case on activation mode. When admin have a condition for user or admin. Place the email stuff in private functions. Put the changes for $user and the call for mail function in the if and else branch. Loose the check on permission of loggedin user..

@pinkeltje: My bad re 3.3.3. I was confused by no mail being sent from the backend. But that is always the case, no new thing. I'll add feature request regarding that.

Back to the case here. I wonder why the condition in line 146 was introduced at all. Its only effect is the mail not going out. It can not have helped against the issue it was supposed to fix.

I'd suggest adding a configurable option for people with higher security requirements: admin approval requires authentication.
If set, check if user is logged in. If not, display message that a login is required. If logged in lacking privileges, display a message that admin rights are required. In both cases do NOT authenticate the account.

If the authentication is not required, activate the account if activate=1 is set and send a message. No checking of authentication required.
Like this:

If (admin activation) {
if (authentication required) {
if (logged in) {
if (authorised) {
activate user
send mail
display message "Account activated, mail sent"
} else {
display message "Not authorised!"
}
} else {
display message "Need to log in first!"
}
} else {
activate user
send mail
display message "Account activated, mail sent"
}
} else {
activate user
display message "Your account is active now!"
}

Maybe you can find a better way of sorting to avoid redundancy.

The reason I called it poorly implemented is because:
-1 Now you need to be logged in at the frontend to get notification to the user.
-2 Not being logged in activates the user but suggests something went wrong and doesn't notify the user.

@sovainfo: I agree with you. And having a test there that checks for authorisation leads to the wrong conclusion that the account could only be activated by an authenticated admin, while in reality it can be activated by anybody who has the link or token.

I think this raises two questions:
a) Do we want the option to activate an account with admin approval but without authentication, i.e. do we think the possesion of the second token is proof enough of the authenticity of the request, as only the admins can have the second token?
b) Is it neccessary to provide an configuration option to force authentication for higher security demands?

My answer to both: yes.

I'd be happy with activation by second token without authentication. For many sites this will be a reasonably secure and easy to handle approach.
I can imagine some sites needing higher security constraints, so the admin must be logged in to activate an account. Else anybody able to guess or intercept the second token can activate an account.

At this stage, I am thinking that f7754e7 solves the issue for a case which is much less likely to happen than when the admin activating is not logged in frontend (Happily, a similar patch was not merged in 2.5.x)
Therefore, as we have to release a 3.3.5 urgently, I think we should revert and take the time to solve this issue fully in 3.4.0.
What do you think?

@infograf768: Happy with your suggestion, as long as we don't forget.

@infograf768 Fully agreement here! Let's bring the version 3.3.5 online and fix this issue in the 3.4 branch.

Preparing PR to revert

Please test
#4390

Fixed via #4390

I was testing this this summer, and I'm grateful that it is fixed with 3.3.7-dev (was kind of lost between issue, PR and comments, while not being in joomla code every day ;-). Checking in 2.5.x now...