Just had a follow up from a client using HikaShop reporting exactly the same problem since August/September, so this seems to confirm that that this was introduced in either version 3.3.2 or 3.3.3.

I have tested this with a clean install of Joomla 3.3.6, with both options for New User Account Activation as well as Notification Mail to Administrators (4 scenarios) and cannot reproduce the issue.

I unfortunately don't have time to test a 3.3.3 to 3.3.6 upgrade, where the issue may occur, but will try to test that scenario soon.

@betweenbrain

Can you confirm that you tested the new user creation from the front-end, as in my description I clearly stated under the "steps to reproduce the issue" that the problem is for a "front-end" user registration, and in your reply it is not clear that this is what you tested.

As far as I am aware there is no problem with creating a new user from the back-end, though I will double check this in the morning when I get in to my office.

Just to follow up on my earlier comments, there are 2 sites that I am aware of where the front-end user registration is an issue.

One of the sites uses the user registration process to allow access to a memebrs only area, and only uses the standard out of the box Joomla installation with minimal optional components (e.g. RS Forms Pro plus a few components that we use as our standard basic setup for all of our clients such as Akeeba backup, JCE Editor and XMap).

The other site also uses our basic setup (as above, but without the RS Forms Pro component), but it also has the HikaShop component, and we need the front-end registration and login in order to add items to the HikaShop shopping cart, but without the front-end registration the shop on this site is next to useless.

I will also test a clean install in the morning to double check in case a component is affecting the registration and login, but I doubt it.

On the first site while it was using Joomla version 3.2.1, the front-end user registration and login were working fine. The last registration that was logged in the user manage showed that the registration and last login was in July 2014.

We upgraded the site to Joomla 3.3.3 in August 2014, and all users that registered after this update (there were 6 at least, plus a number of missing ID numbers that never completed the registration process, so there were gaps in the ID numbers) were never recordeed as having ever logged in.

This could be because they did not attempt to log in, or as I suspect, they were unable to doso, and yet all of the settings appear to be correct.

We last updated Joomla to version 3.3.6 at the begining of this month, but the issue still persists.

@westiefan Apologies for not clarifying before. Yes, my tests were with registering users with the front-end. I'll try to test a site upgraded to 3.3.6 tomorrow if I can.

Looks to me proper procedures are not being followed. You shouldn't activate from the backend. When activation set to Self, there is no need. When set to Admin, you need to use the link in the mail.

Use of the backend to activate is for when you don't allow registration. Mixing the procedures gives you the problems.

@sovainfo it really shouldn't matter if the user is activated from the backend or by him or herself in the frontend. An administrator should alway be able to manage users as needed.

Only saying that is not the way the product works. When you want to improve the product to work like that, fine with me. Issue a improvement PR to make it work like that.

@sovainfo Just to clarify, we did initially have the user activation set to "self" (as noted), and when we checked the back-end the user was listed as being "Enabled" and "Activated", but they still could not log in as they got the same message stating that "Your account has not yet been approved!", so we did follow procedure for the "Self" activated users. I only manually "Enabled" and "Activated" the user when it was set to "Admin" as I do not receive the admin emails, so at that point was only able to do so from the back-end.

Just tested setting up a new registered user in the backend (to possibly use as a work-around while this issue is being resolved), and found a very strange thing happened.

As the user was being set up by a super admin in the back-end you would thing that this in itself would verify the user/email address etc, but apparently this is not the case.

I set up the new user using the same details as I used when setting up a new user in the front-end (after first deleting the test user account so that I can re-use the email address for the new test account), and the system sent me the expected email to notify me of the new user details (e.g. email containing username and password as expected), and the email only contained a link to the site.

When I then visited the site and tried to login, I got the following message, which does not make sense under the circumstances:

"Your registration process is not yet complete! Please check again your email for further instructions that have just been resent. If you don't find the email, check your spam-box. Make sure that your email account options are not set to immediately delete spam. If that was the case, just try logging in again to receive a new instructions email."

I then received a second email notifying me that "Your Registration is Pending Approval", and a it contained a request to verify my test email address (although because I had previously used this email address it also stated that my email address is "already confirmed".

I then tried to log in again and was succesfully able to log in. Just to clarify the back-end settings I checked the account settings and noted that the new account was not "Activated", and yet it had allowed me to log in.

In essence I do not understand what is going on with this relatively basic installation, as I was not expecting to need to verify the user email having created the user in the back-end, as I would have expected (logically speaking) that as I had manually created the account it would have automatically been approved.

Any ideas anyone?

Just a thought.

Although the issue first appeared after the update to Joomla 3.3.2 / 3.3.3, I should also mention that these sites were both updated to Joomla 3.3.4 and subsequently to 3.3.5 before finally being updated to 3.3.6.

Not sure if this has a bearing or not, but just thought that I would mention it so that anyone setting up a test site to duplicate the issue has all of the update information to fully recreate the set up.

Just a quick update, I had a "clean" basic install that I was using for an automated site restoration test that contained only our basic setup (e.g. with the core components as listed previously), and was created using version 3.3.0. I just did a direct upgrade on this test site from version 3.3.0 to version 3.3.6 and the problem does not exist, as I was able to create a new user from the front end, and the activation process was completed as expected, so there were no issues with the clean version of the site.

This then throws up the question of what happened in the versions in between that broke the activation process, as it is clear that the issue does not present itself if the upgrade skips versions 3.3.2 and all interim versions to get to version 3.3.6, or if the installation is made directly from the full 3.3.6 version.

In other words, it looks like clean versions are fine, but something changed at some point in one of the interim versions from 3.3.2 to 3.3.5 that has not fixed itself in the latest version 3.3.6, so whatever happened, it affected the authentication process in such a way that directly upgrading to the next version does not fix it.

Any ideas on what this may be, and more importantly how it can be fixed as it is just not possible to rebuilt the sites from scratch using the latest core version?

@westiefan Can you reliably reproduce the issue if you start with a clean install of 3.3.2 or 3.3.3 and then upgrade it to 3.3.6?

@betweenbrain Not tried it, but will give it a go, but it might take a while, so bear with me. As I stated both of the sites that are affected went through the upgrade path, but both went through different upgrade paths as folows:

Site 1 (basic site - updated as per support schedule): Joomla 3.3.1 -> 3.3.3 -> 3.3.4 -> 3.3.5 -> 3.3.6
Site 2 (basic site with HikaShop - updated during site development): Joomla 3.3.1 -> 3.3.3 -> 3.3.6

I will post the results as soon as I have tested the upgrade paths suggested.

I have tried this and i have followed every steps mention above and found no difficulty in Log In...!! Here Are My Steps:-
step:-1 (my joomla site version updated:- Joomla! 3.3.7-dev Development:-)
step:-2 (Followed every steps mention above)
step:-3 I have log in from front end and and found no difficulty to do it..!

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4681.

Followed every steps and get easily login with no difficulty

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4681.

I Follow Your steps which u mention above but i cant find any error, meance all work perfectly.........

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4681.

As no one has been able to confirm this at this time I am going to mark it as an unconfirmed report. If you are able to provide information that enables others to confirm it then it can be reopened. Thanks

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4681.

Set to "closed" on behalf of @brianteeman by The JTracker Application at issues.joomla.org/joomla-cms/4681

All these people that have supposedly tested it, did they also follow the upgrade path before reporting that they were able to login correctly?

I suspect not. I myself had already stated that upgrading by bypassing certain upgrade packages does not cause the issue, and I am currently running tests to try to identify which upgrade actaully caused the problem, so the least you could do before closing it is to allow me to test and verify the upgrade paths as being the issue (or not as the case may be) as requested by @betweenbrain

Checking the reported "no problem here" as reported by @TasolMarkand, it is clear that he has not followed the upgrade path while carrying out his tests, so I suspect that others have also ignored the specific upgrades that I believe have caused this.

I will be the first to eat humble pie if I cannot provide a clear path to reproduce the error, but at least give me the chance to prove it over the weekend before you dismiss it out of hand.

As I said

• If you are able to provide information that enables others to confirm it then it can be reopened.

It is not being dismissed out of hand - multiple people have tried to replicate it and havent yet

@brianteeman Ok, understood. I will be running a series of tests with the various upgrade paths with a totally clean installation (e.g. no 3rd party components at all with the sole exception of Akeeba backup so that I can quickly restore back to the initial installation for each test etc), and I will report back with a full analysis to confirm the results one way or the other.

Just a thought but if you do replicate it then you could share the jpa from
akeeba backup so people can check

On 17 October 2014 12:05, westiefan notifications@github.com wrote:

@brianteeman https://github.com/brianteeman Ok, understood. I will be
running a series of tests with the various upgrade paths with a totally
clean installation (e.g. no 3rd party components at all with the sole
exception of Akeeba backup so that I can quickly restore back to the
initial installation for each test etc), and I will report back with a full
analysis to confirm the results one way or the other.

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

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@brianteeman will do.

Hi All, I have been testing all weekend so far, and I have to admit defeat.

I have been unable to recreate the error with a clean installation of joomla starting with version 3.3.1 and upgrading through versions 3.3.3, 3.3.4, and up to 3.3.6 (based on a clean install with only the Akeeba Backup component installed, and nothing else).

I have been giving some thought to this and it occurs to me that my default "in house" build that we use as a starting point for Joomla 3 was started in version 3.1.x, and then updated with each new release as and when it became available, so it is entirely possible that there was an issue at some point in a much earlier version that only got triggered as a result of the updtaes after 3.3.1, and I just cannot identify where it is.

With this in mind I am now going to abandon any further testing, and as it has been proved beyond any doubt that a clean istall does not contain the issue, I am now going to rebuild my in house core start (backup) file from a clean installation of Joomla 3.3.6, and will have to bite the bullet and rebuild the 2 sites that have the error from scratch.

At the end of the day I still do not know why there is an error on these 2 sites, and as no one can recreate it with a clean copy of Joomla the chances are the error will never be found and fixed, however, if anyone has the inclination to look into it further, then let me know as I would be happy to provide an Akeeba backup .jpa file from one of the sites containing the error (cleaned of any client information and registered user data of course), as it may be a useful exercise for someone out there.

Loads of humble pie currently being eaten.

I had a similar issue. Was running Joomla 3.1 for a new website build that took many months. Then when I tried to set up my client in the back end as a user which included defining his password I was unable to login. The message in the login window was:
Warning Username and password do not match or you do not have an account yet.

An upgrade to 3.3.6 made no difference. I made numerous repeated attempts with alternative usernames, passwords, etc. All unsuccessful.

Finally discovered that if I tried the new user setup with with:

Receive system emails

Set to No and then login I was successful. After the first login I was able to change this setting to Yes and then continue to login successfully.

Seems to me the humble pie can be substituted for something a little more appetising.

@MarquisMarkie Sorry but that is a completely un-related issue to the one I reported here, but thank you for your comments.

As this issue is now closed I had not expected there to be any further comments unless the issue was to be re-opened, but for the benefit of others that may still be reading this, following all of my testing etc as outlined above, we still needed to solve the issue for our client, and we were on the verge of doing a complete rebuild when quite by pure chance we discovered that the issue was actually caused by a clash with a setting in community Builder.

Apologies to anyone else reviewing or looking into this issue, as due to the fact that this tracker item had been closed I forgot to report that we had (eventually) discovered what the real problem was, and that it actually turned out to be down to a third party component combined with the client not telling me that they had made changes to the CB settings, so we assumed that the issue was related to an update becuase the client reported that the issue only started following a Joomla update, and that it was working fine before the update.

Still trying to swallow the even larger slice of humble pie!!