Only the super user may rescan the links inside a multilingual tree.
Hello
I keep running into this problem. I cannot delete the super user which I presume is the admin user.
It appears that my administrator user cannot achieve anything with a multilingual set up. Iāve read all the previous stuff and doesnāt really help.
Anyone ?
If you donāt have access to the super user account.
Check with whoever installed the site, they will have the account and should be able to either provide the details or give you a reason why not. In general, it is best that non-expert users donāt regularly login as the super user to avoid making mistakes or exposing security gaps.
If you then need to unilaterally become the super user, see @mnakalay ās article for ways to recover the super user password.
Another way is to hack the database directly to copy all the details of another user over the super user record (id=1), then delete the other user.
@andrew this kind of is another case of the āsuper userā being only one user can be problematic. Iām tagging you because Iāve raised other issues over the years of things only the āsuper userā can do that should frankly be permissions any user can be granted (as in, if the website owners want that granting).
As the answer was relatively simple ie add another admin and delete the other, I was surprised that it worked and surprised that super user should still be in use.
Iām of the understanding that even the latest version of Concrete CMS (v9.4.4) still has aspects that are tied to only the Super User. But Iād love to be proven wrong. Last I saw of the topic there was no way to grant all Super User permissions to another user/group/etc. Again, I would love to be wrong because I care about such stuff, but thatās what I know.
Much like Unix, the root āsuper userā (really account #1 in Concrete CMS) is just plain special. When you are logged in as this user the system actually completely by-passes all permission checks. This is extremely handy in case something gets configured in such a way where itās truly inaccessible, which given the complex possibilities with permissions, access entities, exclusions, timed permissions and the like is actually surprisingly feasible.
Generally we try to add task permissions for things that we believe sub-admins might need to do on a larger site over time, but at the end of the day - this underlying architecture isnāt going to change. Itās not that we donāt care about security, quite the opposite. Itās that every so often you may need an account that you canāt configure to be useless no matter how hard you try.
Best practices would be to not really use the admin account unless youāre doing some system wide admin issue that would require it. Much like best practices are taught for using root on a *nix setup.
