AbleCommerce Shopping Cart Software

I want and need my store to be automated. For small companies or companies that only allow certain people to access the admin, when you lock out an account it requires human interaction to re-enable an account. It also frustrates the user. If a user exceeds the failed login attempts the account should lock but only for a set amount of time, i.e. 10 minutes. After which the account show re-enable and they can retry or reset their password. Please automate this so we do not have to manually reset accounts for people. I don't know if this issue occurs in GOLD but if so, please correct/improve this.

There is a Lockout Period that you can set via the Password Policies page. Default value is 10 minutes. I don't think any account ever gets permanently disabled.

Lockout period is set to 5 minutes. I have always had to go unlock accounts for people. The "account disabled" box is checked and I have to uncheck it and I also reset their password for them at the same time. FYI - may be broke...

Katie - can you run a test on this? Trigger an account lockout then come back to it X minutes later where X is your lockout period set in Admin. Is it supposed to remain disabled for admin action? Can the user reattempt another login or password reset? I just want to make sure this behavior is working as intended in GOLD even though I'm seeing this in 707 so when I get to GOLD this is resolved, if needed.

Thx

Tested both Retail and Admin accounts by triggering the lockout period, and returning later to login successfully. It looks like this is working in Gold. I am a bit surprised that this even exists in version 7. This is not a minor issue and surely someone would have reported it..

What are the exact steps you are taking? Maybe I am trying something a little different.

I don't know the steps taking, all I know is the user gets locked out and I have to go in and clear the checkbox that their account is disabled. However, I have never asked them to retry their login, they may be getting locked out and then coming to me with a store assistance e-mail. In these cases too I've seen passwords way old, i.e. > 1000 days. I'll see if I can duplicate it and report back, i.e. see what happens in the lock out state and if the account shows disabled and doesn't clear until another login attempt after the lockout is expired.

Katie, I have never been able to pin down why it is happening, but if we go to a site where we are disabled and the merchant has said they enabled us, we are still disabled. I've never reported anything, thinking it was human error. I'm having that trouble with a Gold site today- merchant has said she enabled me twice, but I'm still showing disabled. We are going to try it while we are both on the phone today.

Judy,

Which version of Gold is this? I just ran across an issue that was fixed in R7.

•[AC8-2242] - Additional checks to make sure User accounts cannot be disabled

This one is R8 in dev, but it was upgraded from Able 7 by the merchant and they want us to fix some problems. Maybe there is something with legacy data. I'll post back if we are able to duplicate the problem.

We are having the same issue as jmestep. A superadmin user account is showing disabled. We enable the user. We insure that the setting is saved by exiting and reopening the customer record. We log out. Next time we log in the account setting is again disabled. This is happening with the same user both on our live site (Gold site VERSION: 7.0.90.8302), and on our dev site (VERSION: 7.0.88.7345). This has never occurred before to our knowledge. Interesting that the same customer is affected in both Able versions.

This is such a rare occurrence that I have to wonder if Judy is right about there being some legacy data coming from AC7.

There is a setting from the Passwords configuration page within the Security menu. You can set the amount of time before an Admin account is disabled due to inactivity. Our default setting is 6 months, but it could be changed via the interface.

Without being able to reproduce something like this, I think that some deeper investigation into the database records needs to happen.

Katie, you may be on to something. The affected superadmin user account had not been used for a couple years.