cms
cms copied to clipboard
craftcms
[4.5.5]: User Permissions incorrect after Craft 3 upgrade
What happened?
Description
I upgraded a site from 3.9 to 4.5.5 and now user permissions are incorrect. The User Groups all have the correct permissions and the User has the correct User Groups assigned, but the permissions do not match.
Steps to reproduce
- Start on Craft 3.9
- Add some User Groups with permission to Edit Entries for a Section
- Add that group to a User
- Upgrade to Craft 4.5.5
- Check the permissions for the user compared to the user group permissions
Expected behavior
User permissions match User Group permissions
Actual behavior
User permissions don't match any User Group
Craft CMS version
4.5.5
PHP version
8.1.22
Operating system and version
Linux 5.15.49-linuxkit-pr
Database type and version
MariaDB 10.4.31
Image driver and version
Imagick 3.7.0 (ImageMagick 6.9.11-60)
Installed plugins and versions
Asset Rev | 7.0.0 Azure Blob Storage | 2.0.0 Calendar | 4.0.9 CKEditor | 3.6.0 Feed Me | 5.2.0 Navigation | 2.0.21 Publisher X | 3.0.1 Redactor | 3.0.4 Redirect Manager | 2.0.0 Snaptcha | 4.0.1 Super Table | 3.0.9 Video Embed | 2.0.2 Width Fieldtype | 4.0.0
I’m not able to reproduce this. Those disabled checkboxes (indicating user group-provided permissions) is just a UI thing; there’s nothing in the database tracking that the user has those permissions specifically. So if they definitely belong to that user group, there’s nothing more that should be needed for the checkboxes to be disabled.
The format for how permissions are specified changed in Craft 4 (see User Permissions in the upgrade guide, and d3d20ba6e4f145d8da78989372ec1e5103678b8e). Maybe you have a plugin or module installed that is getting involved in permissions, which wasn’t updated accordingly?
The user definitely belongs to the group, I even tried removing the group and saving then re-adding the group and saving but the permissions don't update. The only module code we're using that's related is to assign the groups to a user. We take what's returned from the SSO and add those groups in Craft. That appears to be working fine since the user is assigned to the group.
foreach ($roles as $role) {
$userGroupHandle = StringHelper::camelCase($role);
$userGroup = Craft::$app->userGroups->getGroupByHandle($userGroupHandle);
if ($userGroup) {
$groupIds[] = $userGroup->id;
}
}
Craft::$app->users->assignUserToGroups($user->id, $groupIds);
Is that happening on the same request? Maybe it’s an order of operations issue, where the user’s group-supplied permissions are already memoized for the request before you’ve assigned the user groups?
Those groups get set when the user logs in and don't get touched after that. If I edit a user's groups in the CP and remove one, those permissions should be removed on save, correct?
Yeah, and in that case the UI won’t show the updated checkbox states until after save.
Any chance you could send a database backup and your Composer files to [email protected], and point us to a user account that you’re seeing this issue with?
@brandonkelly Was anyone able to take a look at the db and composer files? Anything stick out?
Hey @maxdmyers, sorry we haven’t had a chance to look. The whole team has been away in Barcelona for our Dot All conference. We should be able to get to this tomorrow.
I figured that was the case. 🙂 I hope you all had a great time, and thanks for taking a look!
Upping this because I've had a similar issue after a recent Craft 3 > Craft 4 upgrade. I have a local environment (it matches production, we use docker containers) where the permissions are set and correct, but they do not seem to replicate to our production environment when we deploy.
The user is part of the appropriate User Groups, but looking at the settings list only the 'Create' and 'Delete' permissions are set (on my local environment all of them are set).
We set allowAdminChanges to false on production environments, but rebuilding the project config locally & deploying has not made a difference.
Local:
Production:
We've actually been doing a lot of Craft 3 > Craft 4 upgrades recently, and this is the only time this has happened... Very confusing!
@ameliagroen Would you be able to send your Craft 3 database backup, along with your original and Craft 4-updated Composer files, over to [email protected]?
Hey Brandon
It actually turns that it was a caching issue for us. After clearing the data caches & rebuilding the project config on production it applied the settings as expected! Still odd that the project config wasn't configging, but such is life sometimes, I suppose.
On Tue, 7 Nov 2023 at 18:45, Brandon Kelly @.***> wrote:
@ameliagroen https://github.com/ameliagroen Would you be able to send your Craft 3 database backup, along with your original and Craft 4-updated Composer files, over to @.***?
— Reply to this email directly, view it on GitHub https://github.com/craftcms/cms/issues/13749#issuecomment-1799331441, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF7F7BXVWQDGVFAOLKQV4ATYDJXVFAVCNFSM6AAAAAA5H7D3KKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJZGMZTCNBUGE . You are receiving this because you were mentioned.Message ID: @.***>
Ah, interesting. Still could be helpful to get those files, so we can look into the project config issue, if that’s possible.
We came across a similar issue, but for a new Craft 4 site (so not migrated) without user/permission related plugins. Seems that permission changes via the Yaml files were not applied on the production environment. After "Reapply everything" the permissions were corrected. Can provide database export of the state before "Reapply everything" if needed.
I had this same issue today. Permissions were correct on Production on Craft 3. After updating to Craft 4, most User Groups lost access to Sections and Volumes, despite permissions still being correct in the Yaml files. Clearing caches + "Reapply everything" fixed it.
We uncovered the same issue (it wasn't until after quite sometime though), a user created an entry from a front-end form and it worked but was in a disabled state.
Upgrade Path: 3.9.10 --> 4.8.2
