Customer Accounts Disabled?

[Naveed]

I have reviewed all the related user maintenance implementation. We have proper checks to make sure only to disable inactive admin user accounts and never disable customer accounts (These checks were added for Gold R7 release).

[NC Software]

I had this come up again yesterday so instead of jumping to reset it for him I asked him to try the reset password option to see if he could in fact resolve this without merchant admin interaction. He responded:

I tried the password reset option again this morning and it still says: "the account associated with this address has been deactivated"

So I had to go in to AC 707 admin to reactivate his account and reset his password.

disabled.jpg

[Naveed]

Hi All,

I just want to confirm if anyone able to reproduce this issue for Gold R7 or R8 releases? Though we were not able to reproduce the issue properly, but we made some updates to user maintenance routine for Gold R7 release to avoid this issue. I hope this is fixed for Gold R7 release.

[AbleMods]

I know this is old, but I have some new information. Had a large client see this exact same issue after upgrading 7.0.7 to Gold R10 last week.

The client identified the pattern as all users that are members of the _DEFAULT_ group. Old users not a part of the group were not affected.

I haven't looked to see how the addition to the _default_ group takes place, so I don't have any more details for you.

[Katie]

I ran into a similar issue, but it had to do with an admin account that was disabled. I often use the password reset page to get myself back into an installation, but realized that the script on that page doesn't re-enable a disabled account.

In your case Joe, this is not really related to regular store users, but I wanted to mention in case it triggers something.

[AbleMods]

ok thanks

[Katie]

Joe,

If you would like to setup a temporary admin account for me, I'd be happy to take a look at some of these the user accounts and see if anything looks odd. What is so strange is that the issue has come up on a few different occasions, but if it was a bug, then why isn't it happening all the time?

[AbleMods]

Thanks for the offer Katie.

The client is running a SQL query to re-activate all the accounts. So they're all activated by now. If we see it happen again, we'll definitely get you on board to take a look.

I agree this is odd. The upgrade has been live over a week. The issue wasn't noticed until 6 days after the upgrade. So either nobody said anything, or a maintenance routine is involved somehow. There is no custom code related to users or maintenance in this site, just a bunch of fancy category display pages.

I asked the client if they were an upgrade from 5.5 to 7.x before I updated them to Gold. They couldn't remember for certain, but they have been on Able for a long time. So it's possible there is something to that...

I was going to snoop around the code that handles the _default_ stuff, just to see what's involved there. Just haven't found time today yet to dig a little.

[jmestep]

Joe, when I had it happen, it disabled users based on when the site was set to purge anonymous users, so your site might have that set to 7 days.

[AbleMods]

So running a manual query doesn't help - users just get disabled again during the next maintenance run.

Katie, isn't this the culprit? Note how it's using MERCHANTpasswordpolicy, not CUSTOMERpasswordpolicy. Effectively the routine is applying the merchant inactive user policy to the regular store users. I don't think this code takes into account the new _DEFAULT_ architecture.

Code: Select all

            if (includeInactive)
            {
                MerchantPasswordPolicy policy = new MerchantPasswordPolicy();
                if (policy.InactivePeriod > 0)
                {
                    DateTime dateTime = DateTime.UtcNow.AddMonths(-1 * policy.InactivePeriod);

                    // LOOK FOR INACTIVE USERS IN NON-CONSUMER GROUPS (I.E. HAVE ROLES ASSIGNED)
                    IList<User> users = NHibernateHelper.CreateCriteria<User>("U")
                        .CreateCriteria("U.UserGroups", "UG", NHibernate.SqlCommand.JoinType.InnerJoin)
                        .CreateCriteria("UG.Group", "G", NHibernate.SqlCommand.JoinType.InnerJoin)
                        .CreateCriteria("G.Roles", "R", NHibernate.SqlCommand.JoinType.InnerJoin)
                        .Add(Restrictions.Not(Restrictions.In("R.Name", Role.CustomerRoles))) // exclude the users having customer roles assigned
                        .Add(Restrictions.Eq("U.Store.Id", AbleContext.Current.Store.Id))
                        .Add(Restrictions.Lt("U.LastActivityDate", dateTime))
                        .Add(Restrictions.Eq("U.IsApproved", true))
                        .SetResultTransformer(Transformers.DistinctRootEntity)
                        .List<User>();
                    
                    int expiredCount = users.Count;
                    foreach (User user in users)
                    {
                        if (!user.IsAdmin) continue;
                        if (user.IsAuthorizedUser) continue;
                        user.IsApproved = false;
                        user.Save();
                    }

                    if (expiredCount > 0)
                        Logger.Info("User maintenance disabled " + expiredCount.ToString() + " expired merchant accounts.");
                }
            }

[Katie]

We're going to look into this Joe. Thanks for spending the time looking through the code. This definitely seems suspicious.

[AbleMods]

By the way, this is a 5.5 site that was upgraded to 7 (long time ago) and then eventually upgraded to Gold.

[NC Software]

What is the password age of most accounts you're seeing disabled? In my 707 issue they were typically 1000+ days.

[AbleMods]

The shopper has to be inactive longer than the inactive days setting in the merchant password policy. This client I believe is set to 6 months.

[jmestep]

Yay, Joe! It looks like you might have found it. I remember upgrading one site where the users got disabled every few days and I remember now it corresponded with the admin user password expiration so I had to set that to the maximum time it would take. I know Katie really worked with us to try to find the problem, but it happened on some site, but didn't happen on others.

[nadeem]

Judy, are you able to see this issue after upgrading to the GoldR7+ versions? I have debugged the code and not able to reproduce the issue after we have fixed this in GoldR6 and GoldR7.

Following additional checks have been applied to make sure only the admin accounts can be disabled after the inactivity period set in merchant password policy.

Code: Select all

.Add(Restrictions.Not(Restrictions.In("R.Name", Role.CustomerRoles))) // exclude the users having customer roles assigned

and

Code: Select all

if (!user.IsAdmin) continue;
if (user.IsAuthorizedUser) continue;

Before the above updates, the non-admin users can also be disabled since the query wasn't filtering out users having customer roles. I can easily reproduce this issue by removing the above line of codes.

[NC Software]

Nadeem, I don't think the issue in the recent posts are admins getting disabled but normal users because they are getting evaluated against merchant admin's policy instead of customer policy. But they shouldn't be getting disabled regardless, just prompted to change password if the policy is expiring them.

[jguengerich]

Neal,

I think Nadeem's point is that the code posted by Joe (apparently from R7 and up) will not (based on his testing) disable normal users because of the added restriction in the nHibernate statement that filters out users with customer roles.

[nadeem]

Yes, exactly. Jay, thank you so much for explaining my point correctly.

[Katie]

I just checked a hosted customer that we recently upgraded to Gold. He has been using AbleCommerce for more than 10 years with data coming from version 4.3 to 5.5 to 7.x to Gold. He has over 20,000 users and I just did a spot check to see if any accounts are disabled. I found accounts that haven't been used for over 3000 days and also newly created accounts. They are all active and he has never once complained about accounts being disabled.

I have seen many many upgrades from 7 to Gold, yet there are only a small handful of clients who have this problem. We have also checked, re-checked, and triple checked our code to make sure retail accounts are never disabled. A bug report was opened and fixed in R7. So any install R7 and later should not have this problem.

It is very frustrating to try and solve a problem that we have never been able to reproduce. I have to ask again - does anyone have any customization or plug-in that us related to User Accounts?

[Katie]

The client identified the pattern as all users that are members of the _DEFAULT_ group. Old users not a part of the group were not affected.

Joe, what do you mean when you say you have OLD users that are not part of the _DEFAULT_ group. In the installation I have upgraded, the users date back to 2004, and every single retail user IS part of the _DEFAULT_ group. So, why does your client have some that aren't in this group. Maybe that is what we are missing?

[AbleMods]

So, why does your client have some that aren't in this group.

That's a good question, Katie.

To get total registered users, I run this query:

Code: Select all

select count(*) from ac_users where isanonymous = 0 and isapproved = 1

I get a result of 59,918 records

To get users in the default group, I look up the default group ID which is 27. I then run this query:

Code: Select all

select count(*) from ac_usergroups where groupid = 27

I get 53,804 records

Unless my queries are wrong, there are 6,100+ users which are registered and approved, but not a member of the default group. Not sure this is our issue, but interesting nonetheless.

Now, for the bad news:
I spun the site up in my dev environment with full source code so I could watch the maintenance routine fire. At the time, I had approx. 58,000 disabled users. Before I spun the site up, I re-enabled all the disabled users. I did this hoping to catch maintenance re-disabling the default accounts.

I watched the debug hit the routine 3 times. The first time, it found 4 records. All legitimate, outdated admin users. All 4 were correctly disabled. Nothing was found the 2nd and 3rd runs of the maintenance routine, which is exactly as it should behave.

This is starting to smell like something external is at play here.....

I will say this. I noticed tonight that there are some non-default entries in the ac_Roles table. That's a bit unusual for me to see in an install, most people don't mess with roles.

[jmestep]

Nadeem, I can't remember if it was only one site that had a problem or if there were two. I remember the one site because they launched right before the weekend and thousands of users were disabled. They were R6, but they were not on our servers. She said that there was no other program running to affect users and there was no custom code that would do it. We have upgraded numerous sites since then and they have not had a problem.

[AbleMods]

Update on this issue:

We have disabled maintenance by setting the maintenance interval to zero in the ablecommerce.config file. We then also turned off our manual script to re-enable the disabled users.

We did a run of each of the two plugins in the site, checking disabled users after each run. Neither caused the users to become disabled - everything looks and works great.

We're going to leave maintenance off for a day or two and see how things go. This may not give us a smoking gun, but at least narrows it down a little for us.

[AbleMods]

Well, we're giving up on this issue. We have been unable to prove definitively how the users were getting disabled.

We specifically stopped our manual fix SQL script. We re-enabled maintenance and confirmed it is running. We've run our regular plugins for Quickbooks and shipping like usual.

No disabled users after several days.

I'm baffled - no explanation whatsoever how the behavior is different now. This whole thing smells like some sort of outside SQL update, or perhaps a SQL trigger we don't know about. But after several days, the issue has not returned. I really hate leaving it like this, but I have no choice. The issue simply doesn't happen now.