Branch: refs/heads/master Home: https://github.com/xwiki/xwiki-platform Commit: 46c1457a74674458dd0e9c2e3cdb43b3ce347e67 https://github.com/xwiki/xwiki-platform/commit/46c1457a74674458dd0e9c2e3cdb4... Author: Vincent Massol <[email protected]> Date: 2026-07-25 (Sat, 25 Jul 2026) Changed paths: M xwiki-platform-core/xwiki-platform-administration/xwiki-platform-administration-test/xwiki-platform-administration-test-docker/src/test/it/org/xwiki/administration/test/ui/UsersGroupsRightsManagementIT.java M xwiki-platform-core/xwiki-platform-security/xwiki-platform-security-authorization/xwiki-platform-security-authorization-api/src/test/java/org/xwiki/security/authorization/DefaultAuthorizationManagerIntegrationTest.java A xwiki-platform-core/xwiki-platform-security/xwiki-platform-security-authorization/xwiki-platform-security-authorization-api/src/test/resources/testwikis/groupRightsAtSpaceLevelVersusUserDenyAtWikiLevel.xml Log Message: ----------- XWIKI-24587: Create/check for automated tests for "Deny the rights for a user at wiki level and give rights to a group at page level" The manual test denies the "edit" right to a user at wiki level, then grants view, comment and edit to a group that user belongs to at page level, and expects the user to have no Edit option on the wiki but to have one on that page. No existing test covered that combination: tieResolutionPolicy() pits a user DENY against a group ALLOW but with both rules at the same (wiki) level, the inheritancePolicyFor*() tests do override a wiki-level DENY at a lower level but with user rules only, and UsersGroupsRightsManagementIT.groupRights() sets a page-level group DENY with no wiki-level rule. Add the functional test driving the same UI path as the manual test: deny from Administer Wiki > Users & Rights > Rights > Users, then grant from Administer Page > Users & Rights > Rights: Page & Children. It asserts the Edit option is absent on a page outside the space and present on the granted page. The two assertions cross-validate each other, so the test cannot pass vacuously: the first one proves the wiki-level deny is really in effect, hence the second one can only pass if the page-level group rules override it. Also pin the underlying authorization semantics at the settler level with a testwiki fixture, so that a regression in the rule resolution fails in under a second rather than only inside the Selenium run. A velocity hasAccess() probe against the running instance confirmed both levels agree: the user genuinely holds the edit right on the granted page, so the visible Edit option is not a side effect of the comment right. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-platform/settings/notifications