Skip to content

fix(manager): stop the false privilege error after changing a password - #2556

Merged
Seiger merged 3 commits into
evolution-cms:3.5.xfrom
elcreator:fix-change-password-privilege-error-3.5
Nov 5, 2026
Merged

Seiger merged 3 commits into
evolution-cms:3.5.xfrom
elcreator:fix-change-password-privilege-error-3.5

Conversation

@elcreator

Copy link
Copy Markdown

Fixes #2553.

Problem

A manager without edit_user who changes their own password gets "You don't have enough privileges for this action!" and loses the tab, although the password has changed.

ChangePassword::process() saves the password, then always redirects to a=99, the user list, and the list requires edit_user. Traced in Chrome on an Editor: 302 -> a=99, the alert, the tab closes.

The default Publisher has edit_user, so with the seeded roles only the Editor reproduces it; a Publisher role without that permission behaves the same.

Changes

One commit each:

  • Change password: the save lands on the dashboard (a=2), where the form's Cancel button already goes and which no role is refused. This applies to every role, so administrators land there too instead of on the user list.
  • Change password page lock: Password::checkLocked() refused anyone who opened the page while another manager had it open, with the same privilege message. The form only changes the viewer's own password, so there is nothing to conflict with, and the lock is gone.
  • Delete user: DeleteUser had the same redirect. A role with delete_user but no edit_user deleted the user and then got the error. It now goes to the list only with edit_user, otherwise to the dashboard. Such a role has no link to this action, so this takes a direct URL with a valid token.

There is still no success message after saving a password, as before. It would need a new lexicon key and translations, so it is left out.

Verification

  • tests/Unit tests/Feature on PHP 8.4 (Linux): 2253 passed, 9 skipped. PHPStan: no errors.
  • New tests: ChangePasswordRedirectTest, PasswordPageLockTest, DeleteUserRedirectTest, each failing before its fix. The two redirect tests read the source, because process() ends in exit().
  • In Chrome on a fresh 3.5.x install, before and after each fix: Editor, Publisher and Administrator saving a password (the new one logs in, the old one is refused), two real browsers on the form at once, and a delete with and without edit_user (the list still opens with it).

🤖 Generated with Claude Code

elcreator and others added 3 commits November 5, 2026 17:09
…ion-cms#2553)

The save redirected to the user list, which needs edit_user, so a role
without it saw "You don't have enough privileges" and lost the tab even
though the password had changed.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The form changes the viewer's own password only, yet a second manager
opening it while another had it open was refused with the privilege
error.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A role with delete_user but not edit_user deleted the user and then got
the privilege error from the list. It now lands on the dashboard.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@Seiger
Seiger merged commit c681d06 into evolution-cms:3.5.x Nov 5, 2026
15 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants