Description:
When attempting to edit a user in Part-DB 2.9.1, a 403 Access Denied error is returned. This affects the POST request when saving changes - the edit form loads correctly, but saving fails.
Root Cause:
BaseAdminController.php line 199 calls:
$this->denyAccessUnlessGranted('edit', $entity);
However, config/permissions.yaml does not define an edit operation for the users permission. Other entities (parts, storelocations, categories, etc.) have edit defined, but users only has specific operations like edit_username, edit_infos, edit_permissions, etc.
The UserVoter checks if the attribute is a valid operation for users, and since edit isn't defined, the voter abstains, resulting in access denied.
Steps to Reproduce:
- Install Part-DB 2.9.1
- Log in as an admin user with full permissions
- Navigate to Users → Edit any user
- Make a change and click Save
- Receive 403 Forbidden error
Expected Behavior:
User should be saved successfully.
Workaround:
Add the edit operation to config/permissions.yaml under users: operations::
edit:
label: "perm.edit"
alsoSet: ['read', 'edit_username', 'edit_infos']
apiTokenRole: ROLE_API_ADMIN
And add "edit": true to the users section in the permissions_data JSON for affected users/groups.
Environment:
- Part-DB Version: 2.9.1
- Installation: Docker (jbtronics/part-db1:latest)
- Database: SQLite (migrated from 2.7.1)
Description:
When attempting to edit a user in Part-DB 2.9.1, a 403 Access Denied error is returned. This affects the POST request when saving changes - the edit form loads correctly, but saving fails.
Root Cause:
BaseAdminController.php line 199 calls:
$this->denyAccessUnlessGranted('edit', $entity);
However, config/permissions.yaml does not define an edit operation for the users permission. Other entities (parts, storelocations, categories, etc.) have edit defined, but users only has specific operations like edit_username, edit_infos, edit_permissions, etc.
The UserVoter checks if the attribute is a valid operation for users, and since edit isn't defined, the voter abstains, resulting in access denied.
Steps to Reproduce:
Expected Behavior:
User should be saved successfully.
Workaround:
Add the edit operation to config/permissions.yaml under users: operations::
edit:
label: "perm.edit"
alsoSet: ['read', 'edit_username', 'edit_infos']
apiTokenRole: ROLE_API_ADMIN
And add "edit": true to the users section in the permissions_data JSON for affected users/groups.
Environment: