Cannot Delete Users - Get Logged out
Permalink 3 users found helpful
When I go into the dashboard, logged in as the original admin who started with this install, and go to Search Users, and use the tick box to select a user, and then choose from **With Selected to select Delete - I get a lightbox window that says:
Delete
Users you don't have permission to bulk delete have been removed from this list.
And there are no users listed - meaning I cannot delete this user this way.
AND - it seems this is the case because for some reason I have been logged out of the site for some reason. I know that because when I close that "Delete" window and try to do anything from there, I am kicked out of the site to the login page with this url extension:
index.php/login/account_deactivated
and this message:
"This user is inactive. Please contact us regarding this account."
BUT
If instead, logging in again, on the Search Users page I click on a users name and delete the user from there, it works fine.
Anyone had this issue or have any insight into why this might be happening?
Delete
Users you don't have permission to bulk delete have been removed from this list.
And there are no users listed - meaning I cannot delete this user this way.
AND - it seems this is the case because for some reason I have been logged out of the site for some reason. I know that because when I close that "Delete" window and try to do anything from there, I am kicked out of the site to the login page with this url extension:
index.php/login/account_deactivated
and this message:
"This user is inactive. Please contact us regarding this account."
BUT
If instead, logging in again, on the Search Users page I click on a users name and delete the user from there, it works fine.
Anyone had this issue or have any insight into why this might be happening?
Anyone have this problem? Or have any thoughts as to what could create such a problem?
I see the same behavior with a site I'm working on. I am unable to use any of the actions users selected with search users. Any attempt logs me out even as the super user ID 1. Once selecting a user I can perform all actions on the view user page.
Glad to see I am not the only one. Would be great to have someone look into this.
I am having the same problem. The issue extends to the file manager as well: trying to update a file property automatically logs you out with the same result.
The strange thing is that I developed a website on my server and replicated it on another hosting platform. When using the user delete and file manager functions on my server, I encounter no problems. It seems to occur only on the other hosting platform.
I assume it has to do with folder permissions(?) or server settings(?). have no idea but am looking into this.
Will keep you updated if I come across anything.
The strange thing is that I developed a website on my server and replicated it on another hosting platform. When using the user delete and file manager functions on my server, I encounter no problems. It seems to occur only on the other hosting platform.
I assume it has to do with folder permissions(?) or server settings(?). have no idea but am looking into this.
Will keep you updated if I come across anything.
thanks
Any updates on this? I'm also experiencing automatic log out when editing user properties... The session uID appears to turn into the user I've tried to edit, I've not tracked down why yet though (global $uID somewhere maybe?)
As best as I know, it is a known bug and unfixed. I heard that not from someone at C5, but another programmer who works with C5.
uswebdesigner / others,
Spent quite a few hours tracing this, largely with a degree of bewilderment, but I've finally found the cause. The fault is arguably in our PHP configurations rather than Concrete5 itself, I hadn't realized but we were using "register_globals = On" (http://php.net/register-globals) to support some old OsCommerce installs on our server. This setting means Concrete5 is overwriting a global $u in some requests which it later relies on holding the current logged in user. If you want to run Concrete5 then it looks like we have to make "register_globals = Off" (or you could ini_set in the top of index.php or something to disable it, whatever floats your boat). It might be wise if Concrete5 themselves use ini_set to force the register_globals to Off in their releases now we know it's not compatible...
Cheers,
Mark
Spent quite a few hours tracing this, largely with a degree of bewilderment, but I've finally found the cause. The fault is arguably in our PHP configurations rather than Concrete5 itself, I hadn't realized but we were using "register_globals = On" (http://php.net/register-globals) to support some old OsCommerce installs on our server. This setting means Concrete5 is overwriting a global $u in some requests which it later relies on holding the current logged in user. If you want to run Concrete5 then it looks like we have to make "register_globals = Off" (or you could ini_set in the top of index.php or something to disable it, whatever floats your boat). It might be wise if Concrete5 themselves use ini_set to force the register_globals to Off in their releases now we know it's not compatible...
Cheers,
Mark
Thanks Mark. That was the solution for me. I changed register globals to Off and now I can delete en mass.
Awesome!
Awesome!
It looks like the permission has been reset. So you need to put it back. Here is the process.
Go to dashboard -> System & Settings -> Permissions & Access -> User Permissions. Then check whether the "Delete User" has the Administrator permission Assigned.
A screenshot attached.
Rony
Go to dashboard -> System & Settings -> Permissions & Access -> User Permissions. Then check whether the "Delete User" has the Administrator permission Assigned.
A screenshot attached.
Rony
That was not my case, but thanks for the heads up. It may be for others who find their way here.
