1
votes

Running Liferay 6.2 CE on Tomcat 8.0.20, on two different environments.

On one environment, the dockbar has recently ceased appearing on the top of my Liferay portal when logged as admin. Also, trying to access the Liferay control panel directly with the URL takes me to a "not found" page.

I wonder if it could be a user-administration problem, for a few reasons:

  • The "portal-normal.vm" Velocity file in my theme contains the portion of code which rules the inclusion of the dockbar:

    #if ($is_signed_in && $permissionChecker.isOmniadmin())
    #dockbar()
    #end
    

I found out that when logging as admin, $permissionChecker.isOmniadmin() returns "false", which doesn't look normal to me (but maybe I'm wrong?).

  • When the same portal code (theme and portlets) is deployed in the other environment, logging as admin brings me everything I expect ($permissionChecker.isOmniadmin() == true, dockbar, control panel...).

Please, is there a way to fix this?

EDIT 2018/09/07: I also posted an updated version of that post in the Liferay Community forums. Sorry for cross-posting - these are my first steps on Stack Overflow, I'll be more cautious from now on.

https://community.liferay.com/forums/-/message_boards/message/110891530

2
I see. Thanks, and apologies, I didn't mean to annoy anyone. Should I "close" this topic, or something?Benoît Smith
At a minimum: Link between both posts, so that there's a hint that this might be answered elsewhere. Ideally you'll decide for one post in one place, but now that it's here, a link (in both directions) helps to prevent duplicate work.Olaf Kock
Thank you. I'll do that way.Benoît Smith

2 Answers

0
votes

Just being Administrator doesn't qualify for being an OmniAdmin. There's a configuration, to promote any user an OmniAdmin so that you can gain access even when you've locked yourself out, e.g. nobody knows an Administrator account.

From portal.properties:

Omniadmin users can administer the portal's core functionality: gc, shutdown, etc. Omniadmin users must belong to the default company.

Multiple portal instances might be deployed on one application server, but not all of the administrators should have access to this core functionality. Input the ids of users who are omniadmin users.

Leave this field blank if users who belong to the right company and have the Administrator role are allowed to administer the portal's core functionality. Defaults:

omniadmin.users=

Using this backdoor naturally requires file system access (e.g. you'll need to edit portal-ext.properties) and a restart.

Coming back to your problem: It seems that your theme makes the wrong assumption and you should rather test the permission checker for the current user being member of the Administrator role

0
votes

It was a data issue. By querying the Users_Roles tables in the DB, I found out that for some unclear reason, the "admin" user actually had only a "User" role, missing the "Administrator" and "Power user" roles that it should have had. Without any other "Administrator" user account, I corrected that anomaly in an unrecommended way - by inserting the missing roles into the Users_Roles table (with the application server temporarily shut down, of course). So far, everything seems to have gotten back to normal, so I guess that counts as a solution.