User privileges disappeared?

[brandonw_eln]

I have two OJS installations running on the same server in virtual hosts. They’re configured pretty much identically, and they have the primary admin user. In site #1 I have been creating test journals and creating new users. Site #2 has only the one admin user, no other users.

Today I started working in site #2, and discovered that my user does not have the same privileges as the user in site #1:

• If I click the Administration link from the user dropdown, I get “Access denied”
• If I do go to Site Settings (at index.php/index/admin/settings), the only option I see is Language selection. All the other tabs and options, present in site #1 (Settings, Navigation, Information, Appearance, Plugins) are missing.

I have to assume I somehow lost my role as site administrator, but how could that have happened? And how can I get it back?

Application Version: OJS 3.3.0

[asmecher]

Hi @brandonw_eln,

Here’s a posting about how to grant a Site Administrator role to someone – but I think you might need to double-check the data in the user_user_groups table to see what roles your user already has…

Regards,
Alec Smecher
Public Knowledge Project Team

[brandonw_eln]

Hi Alec – it looks like you might have intended to include a link with that message, but no link is showing… Can you please post it? I’d be happy to look.

I’m not sure why my user would have lost its privileges, though. There is currently only one user in the system.

Here’s what I get for user_user_groups:

MariaDB [subtest_db]> select * from user_user_groups;
+---------------+---------+
| user_group_id | user_id |
+---------------+---------+
|             1 |       1 |
|             2 |       1 |
+---------------+---------+

[asmecher]

Hi @brandonw_eln,

Sorry, you’re correct, I meant to link here:

Changing a site administrator

Hi @Evandro_Souza, Check what the user group ID of your administrators group is by running: SELECT user_group_id FROM user_groups WHERE context_id=0 AND role_id=1; It’ll probably give you a 1 back as a result. Then, you can grant that to your user: INSERT INTO user_user_groups (user_id, user_group_id) VALUES (1234, 1); …where 1234 is your user ID, and 1 is the user_group_id you got from the first query (probably a 1). Regards, Alec Smecher Public Knowledge Project Team

Do you see the same user_user_groups contents in both installs?

Regards,
Alec Smecher
Public Knowledge Project Team

[brandonw_eln]

@Changing a site administrator Software Support

SELECT user_group_id FROM user_groups WHERE context_id=0 AND role_id=1;

Thanks! Yes, both installs have user 1 in groups 1 and 2. The install where admin privileges are working also has user 1 in a few other groups.

So based on this, everything should be working correctly for this user, but somehow I cannot access the things I should be accessing. Would the right thing to do here be to remove user 1 from group 2 and make them exclusively a member of group 1?

[asmecher]

Hi @brandonw_eln,

It’s not going to be 100% reliable to exchange group IDs (the 1 and 2 you’re talking about) between installations – these are references to the group_id column in the user_groups table. There, context_id will refer to a journal_id in journals to indicate which journal the enrollment represents, and role_id will be the numeric code indicating the permission level to the OJS source code.

Since that’s probably clear as mud, here’s how list permission levels for a user for each journal:

SELECT CASE WHEN ug.context_id=0 THEN '(site wide)' ELSE ug.context_id END AS journal_id, ug.role_id AS role_id
FROM user_groups ug JOIN
user_user_groups uug ON (ug.user_group_id = uug.user_group_id)
WHERE uug.user_id=1 ORDER BY ug.context_id;

Regards,
Alec Smecher
Public Knowledge Project Team

[brandonw_eln]

The problem here is not permissions for individual journals, but for the whole site.

The sole user of the site is theoretically the administrator, and has access to Site Settings and all that other stuff, but is missing a lot of the options that should be there.

Is this a permissions/roles thing, or is it possibly something else?

[asmecher]

Hi @brandonw_eln,

The difference will either be in the code or the database, and site-wide role information is stored in the tables referenced in the query above, so it’s worth checking.

Regards,
Alec Smecher
Public Knowledge Project Team

[brandonw_eln]

@asmecher

SELECT CASE WHEN ug.context_id=0 THEN '(site wide)' ELSE ug.context_id END AS journal_id, ug.role_id AS role_id
FROM user_groups ug JOIN
user_user_groups uug ON (ug.user_group_id = uug.user_group_id)
WHERE uug.user_id=1 ORDER BY ug.context_id;

OK, so I tried your query…

+-------------+---------+
| journal_id  | role_id |
+-------------+---------+
| (site wide) |       1 |
| 1           |      16 |
+-------------+---------+

It looks from this that since my user has user_group_id 1, it should have full access, is that right?

So group 1 is the admin role, and user 1 is the user, and user 1 is in both group 1 and group 2.

> select * from user_user_groups;
+---------------+---------+
| user_group_id | user_id |
+---------------+---------+
|             1 |       1 |
|             2 |       1 |
+---------------+---------+

Should I remove the second row from the above table and see if that helps?

[brandonw_eln]

Update: I tried deleting that row; it didn’t work.

DELETE FROM user_user_groups WHERE user_group_id=2 AND user_id=1;

I still am missing all those options from Site Administration.

So, the user is User 1, and is the Site Administrator. He has no other roles at this point. But he is still missing all these options.

I’m really at a loss here. Is there any other way to diagnose this?

[asmecher]

Hi @brandonw_eln,

Rather than focusing on the ROLE_ID_SITE_ADMIN (role_id=1) role, you might want to look at your two accounts’ assignments to the ROLE_ID_MANAGER role (role_id=16). When a Site Administrator creates a new journal, they are automatically assigned a Journal Manager role in that journal. If that’s the case in one of your journals but not the other, that could account for the difference.

Regards,
Alec Smecher
Public Knowledge Project Team