[elcreator]

Brings everything merged into 3.5.x since the last sync into 3.6.x, together with #2572, which is still open against 3.5.x.

3.5.x PRs included: #2544 #2549 #2550 #2551 #2554 #2556 #2558 #2562 #2565 #2566 #2567 #2568 #2569 #2570 #2571 #2573 #2574 #2575 #2576, plus #2572.

Conflicts and how they were resolved

• core/composer.lock: 3.6 keeps its own lock. Its symfony 8.1.11 already includes the fixes for the 2026-11-04 advisories that 3.5 took in b0c2f3a.
• core/vendor/*: git-ignored on 3.6, so it stays deleted.
• SiteUpdateCommand: the update now runs inside ComposerEnvironment (3.5, fe8dd19), which sets COMPOSER_HOME and COMPOSER_AUTH before the overlay. 3.6's configureComposerHome() did nothing after that, so it is removed along with its two tests; ComposerEnvironmentTest covers their cases (legacy site auth, implicit or explicit home, a worker without a home).
• files.php, files.dynamic.php, shared-type-root-request.php: the file manager root comes from fileManagerRoot() (fix(manager): contain a per-user filemanager_path within the system root #2571).

3.6-specific follow-ups

• SystemFilesChecksum::RELEASED lists 3.6's index.php as the current shipped copy (manager/index.php is the same as 3.5's), so an update from any 3.5 release to 3.6 does not report it as modified.
• The save_settings test fixture provides the ManagerTheme facade, which the 3.6 processor uses to remove the compiled theme stylesheet.

Verification

• Merges into the current 3.6.x without conflicts.
• Full suite in evo-ci-php:8.4: 2674 passed, 12 skipped.
• PHPStan: no errors, as on 3.6.x.
• The save_settings tests also pass on MariaDB 11.4 (utf8mb4_general_ci and utf8mb4_unicode_ci).
• Every 3.x release copy of index.php and manager/index.php is in RELEASED, and the last entries match this tree.

🤖 Generated with Claude Code

[MiddleSokilAI]

One upgrade case still looks worth fixing before merging b64350b. In UserRole.php (around lines 247–271), the new role reach checks compare the target role's stored grants with the actor's defined permission keys. Older installations can still have the obsolete role_actionok grant from the previous default seeders. Updating the seed data does not remove that existing row, and I could not find an upgrade cleanup for it.

That can leave a non-administrator role manager unable to edit, delete or assign a legacy default role even when they hold every real permission it grants: the obsolete grant remains on the target side but can never appear among the actor's defined permissions.

Please either migrate/clean up those obsolete grants or consistently restrict the comparison to defined permissions, while preserving the checks for all legitimate permissions. An upgrade regression test should start with the pre-existing obsolete grant, verify the allowed role operations, and still reject operations when the actor lacks a real permission required by the target role.

This is a static review finding; I have not reproduced it at runtime.

SokilAI

[elcreator]

Thanks, confirmed at runtime: the save was refused. The reach checks come from 3.5.x, so the fix is #2578 against 3.5.x, merged here in 95d7b68.

Confirmed: the default Editor role on an upgraded site holds edit_document, save_document and the obsolete role_actionok. A role manager holding every real permission of that role was refused saving it. The same happened with an always-on permission: a role save stores it on the target, and on those sites action_ok is still defined as always-on. When the actor's role was saved before that, the actor lacked it.

Fix: I restricted the comparison rather than adding a cleanup migration, so it covers any grant left without a definition, not just role_actionok. RoleGuard::reachOf($roleId) returns only a role's grants of defined permissions that a role may hold or not (permissions.disabled = 0). Both reach checks use it: role save and delete (guardRoleReach()) and role assignment in EditOrNewUser. Every real permission still counts, and the administrator role stays out of reach.

Upgrade regression test (RoleReachLegacyGrantsTest): it starts with the obsolete role_actionok grant, plus action_ok defined as always-on and granted to the target role, and runs the real controller paths:

• allowed: save, assign and delete for an actor holding every real permission of the role;
• refused on all three: when the actor lacks one of the role's real permissions, or when the role also holds settings;
• the administrator role stays refused.

The allowed case fails on b64350b.

Full suite on this branch: 2680 passed, 12 skipped (3.5.x: 2476 passed). It still merges into 3.6.x without conflicts.