There are 6 updates, 2 comments.
 
 
XWiki Platform / cid:jira-generated-image-avatar-45594dd4-cbd4-4d8f-aacc-77cb3ac09407 XWIKI-24587 Closed

Create/check for automated tests for "Deny the rights for a user at wiki level and give rights to a group at page level"

 
View issue   ·   Add comment
 

6 updates

 
cid:jira-generated-image-avatar-bfbeaafb-9970-46a7-89c1-767a7fcce69d Changes by Vincent Massol on 25/Jul/26 12:14
 
Fix Version: 18.7.0-rc-1
Documentation in Release Notes: N/A
Documentation: N/A
Resolution: Fixed
Tests: Integration
Status: Open Closed
 
 

2 comments

 
cid:jira-generated-image-avatar-bfbeaafb-9970-46a7-89c1-767a7fcce69d Vincent Massol on 25/Jul/26 12:12
 

Checked first whether the scenario was already covered — it was not.

The nearest existing tests each miss the specific combination (wiki-level user DENY + page-level group ALLOW):* DefaultAuthorizationManagerIntegrationTest.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 — no groups involved.
  • UsersGroupsRightsManagementIT.groupRights() sets a page-level group DENY, with no wiki-level rule.
  • The LegacyTestWikiTest fixture happens to contain the mirror rule shape, but never asserts the resulting edit outcome.

Added in commit 46c1457a746 on master:

  1. UsersGroupsRightsManagementIT.allowGroupRightsAtPageLevelWhenUserRightDeniedAtWikiLevel() — a functional test driving the same UI path as the manual test: create the user, the group and the membership, deny edit from Administer Wiki > Users & Rights > Rights > Users, create the page, grant view/comment/edit to the group from Administer Page > Users & Rights > Rights: Page & Children, then log in as the user. It asserts that the Edit option is absent on a page located outside that space and present on the granted page.
  2. DefaultAuthorizationManagerIntegrationTest.groupRightsAtSpaceLevelVersusUserDenyAtWikiLevel() and its testwiki fixture — pins the same semantics at the authorization-settler level, so that a regression in the rule resolution fails in under a second instead of only inside the ~3.5 minute Selenium run.

Notes on the verification:

  • The two functional assertions cross-validate each other, so the test cannot pass vacuously: the first one proves the wiki-level deny is really in effect for that user, hence the second one can only pass if the page-level group rules override it.
  • A velocity hasAccess() probe against the running instance returned view=true comment=true edit=false on a page outside the space and view=true comment=true edit=true on the granted page. The user therefore genuinely holds the edit right on the granted page — the visible Edit option is not a side effect of the comment right.
  • Both expected results of the manual test are thus confirmed: page-level rights granted to a group do take precedence over a right denied to one of its members at wiki level.

Verified on master: the functional test passes (Tomcat + PostgreSQL), the whole DefaultAuthorizationManagerIntegrationTest class passes (18 tests, no regression on the 17 pre-existing ones), and -Plegacy,quality passes on the security module (127 tests, 0 Checkstyle violations, JaCoCo check satisfied).

 
cid:jira-generated-image-avatar-bfbeaafb-9970-46a7-89c1-767a7fcce69d Vincent Massol on 25/Jul/26 12:14
 

Ilie Andriuta please mark as automated, thx!