Checked whether an automated test already existed for this manual test: there was none.
The closest existing tests are DefaultAuthorizationManagerIntegrationTest#groupRightsAtSpaceLevelVersusUserDenyAtWikiLevel (a page-level allow winning over a wiki-level deny) and #documentCreator (which rights a creator gets on its own document). Neither asserts that a document-level deny has no effect on a user having the admin right at wiki level. On the functional side, UsersGroupsRightsManagementIT does drive the rights editor including denies, but always as superadmin and never against an admin user.
Added the test at the authorization-engine level rather than as a functional test. The expected result of the manual test — "even as the page creator, U1 can't Deny any rights to that page to the Admin" — is pure authorization semantics, and it is pinned there in under a second instead of a few minutes of browser time. The engine has no notion of who authored a rule, so the "as the page creator" framing is not representable at that level; the rights-editor path it refers to is however already exercised by UsersGroupsRightsManagementIT.
The behaviour being pinned: Right.ADMIN implies VIEW and is declared with inheritanceOverridePolicy = false, so the wiki-level implied view is not overridden by the rules defined at document level.
Test added: DefaultAuthorizationManagerIntegrationTest#documentDenyVersusAdminRightAtWikiLevel, with a new testwikis/documentDenyVersusAdminRightAtWikiLevel.xml fixture — a wiki granting the admin right to userAdmin, and two documents created by userA: one denying view to userAdmin and to userB, one allowing view to userA only and denying it to userAdmin. The same deny rule strips view from the simple user userB but leaves userAdmin with it; that contrast is what keeps the assertion from being vacuous.
Checked whether an automated test already existed for this manual test: there was none.
The closest existing tests are {{DefaultAuthorizationManagerIntegrationTest#groupRightsAtSpaceLevelVersusUserDenyAtWikiLevel}} \(a page\-level allow winning over a wiki\-level deny\) and {{#documentCreator}} \(which rights a creator gets on its own document\). Neither asserts that a document\-level deny has no effect on a user having the admin right at wiki level. On the functional side, {{UsersGroupsRightsManagementIT}} does drive the rights editor including denies, but always as superadmin and never against an admin user.
Added the test at the authorization\-engine level rather than as a functional test. The expected result of the manual test — "even as the page creator, U1 can't Deny any rights to that page to the Admin" — is pure authorization semantics, and it is pinned there in under a second instead of a few minutes of browser time. The engine has no notion of who authored a rule, so the "as the page creator" framing is not representable at that level; the rights\-editor path it refers to is however already exercised by {{UsersGroupsRightsManagementIT}}.
The behaviour being pinned: {{Right.ADMIN}} implies {{VIEW}} and is declared with {{inheritanceOverridePolicy = false}}, so the wiki\-level implied view is not overridden by the rules defined at document level.
Test added: {{DefaultAuthorizationManagerIntegrationTest#documentDenyVersusAdminRightAtWikiLevel}}, with a new {{testwikis/documentDenyVersusAdminRightAtWikiLevel.xml}} fixture — a wiki granting the admin right to {{userAdmin}}, and two documents created by {{userA}}: one denying view to {{userAdmin}} and to {{userB}}, one allowing view to {{userA}} only and denying it to {{userAdmin}}. The same deny rule strips view from the simple user {{userB}} but leaves {{userAdmin}} with it; that contrast is what keeps the assertion from being vacuous.
