September 2026 - notifications

[xwiki/xwiki-dev-llm]
by XWiki Notifications 17 Sep '26

17 Sep '26

Branch: refs/tags/v1.11.0 Home: https://github.com/xwiki/xwiki-dev-llm To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-dev-llm/settings/notifications

1 0

[xwiki/xwiki-dev-llm] 14219f: [Misc] Release 1.11.0
by XWiki Notifications 17 Sep '26

17 Sep '26

Branch: refs/heads/master Home: https://github.com/xwiki/xwiki-dev-llm Commit: 14219f93325a9cbec01ab01aa14fe38ef169e3da https://github.com/xwiki/xwiki-dev-llm/commit/14219f93325a9cbec01ab01aa14fe… Author: github-actions[bot] <41898282+github-actions[bot](a)users.noreply.github.com> Date: 2026-09-17 (Thu, 17 Sep 2026) Changed paths: M .claude-plugin/marketplace.json M kimi.plugin.json M opencode.jsonc M xwiki/.claude-plugin/plugin.json Log Message: ----------- [Misc] Release 1.11.0 * skill added: xwiki-ci-check To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-dev-llm/settings/notifications

1 0

[xwiki/xwiki-dev-llm]
by XWiki Notifications 17 Sep '26

17 Sep '26

Branch: refs/heads/ci-check-skill Home: https://github.com/xwiki/xwiki-dev-llm To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-dev-llm/settings/notifications

1 0

[xwiki/xwiki-dev-llm] e975ac: [Misc] Add the xwiki-ci-check skill, the daily act...
by XWiki Notifications 17 Sep '26

17 Sep '26

Branch: refs/heads/master Home: https://github.com/xwiki/xwiki-dev-llm Commit: e975ac0571e6d52f1e3d80e8b67e35c92f6c1aec https://github.com/xwiki/xwiki-dev-llm/commit/e975ac0571e6d52f1e3d80e8b67e3… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-17 (Thu, 17 Sep 2026) Changed paths: M README.md M xwiki/okf/index.md M xwiki/okf/servers/jenkins.md M xwiki/scripts/jenkins.mjs A xwiki/scripts/jira-flickers.mjs A xwiki/scripts/routine-setup.sh A xwiki/skills/xwiki-ci-check/SKILL.md A xwiki/skills/xwiki-ci-check/routine-prompt.md A xwiki/skills/xwiki-ci-check/tools/ci-check.mjs A xwiki/skills/xwiki-ci-check/tools/commit-comment.mjs A xwiki/skills/xwiki-ci-check/tools/matrix.mjs A xwiki/skills/xwiki-ci-check/tools/privatebin.mjs M xwiki/skills/xwiki-release-test-triage/SKILL.md M xwiki/skills/xwiki-release-test-triage/tools/triage.mjs Log Message: ----------- [Misc] Add the xwiki-ci-check skill, the daily acting CI sweep * Add skills/xwiki-ci-check: explicit-invocation-only, writes gated behind --write, with a 7-day blame horizon and a per-run budget of 5 deep-treated incidents and 2 fix PRs * Add tools/ci-check.mjs, read-only by construction: discovers the jobs from Jenkins, classifies every red build, groups symptoms into incidents, ages and attributes them, and emits a pre-digested JSON work order * Add tools/privatebin.mjs (PrivateBin v2 client, no dependencies, --self-test), tools/matrix.mjs (digest poster) and tools/commit-comment.mjs, which owns both ends of the marker contract that stops the next run repeating itself * Add routine-prompt.md, the thin prompt the scheduled routine is given * Extract the open-flicker JIRA lookup into scripts/jira-flickers.mjs, shared with xwiki-release-test-triage * Add stagesOf()/failedNodesOf()/logUrlOf()/stepLog()/stepConsole()/grepLog() to scripts/jenkins.mjs: a platform build's consoleText is ~80 MB with no Content-Length and no Range support, so a failure is diagnosed through the Pipeline Stage View API instead * Parse the step log as the JSON envelope it is: wfapi/log returns {nodeId,length,hasMore,text,consoleUrl} with the log in text and its newlines escaped, so reading the body as text yields a single line and no per-line pattern can ever match. It is also only the last ~10 KiB, start being ignored, which puts Maven's "Failed to execute goal ... on project X" above the window and leaves "mvn <args> -rf :<module>" inside it — hence one fallback to the node's console page for a stage the tail could not explain * Classify from the first failed stage alone, never pooled: a broken build fails in a cascade (Main, then TestRelease, then the quality gate), and letting the highest-priority matcher anywhere in the pile decide makes the diagnosis depend on how far the cascade ran, so two builds of one unchanged break sign differently and the blame window collapses onto the last build's commits * Match the quality gate on Jenkins' own wording too ("Pipeline aborted due to quality gate failure"), which is what waitForQualityGate puts in the stage error; the scanner's "QUALITY GATE STATUS: FAILED" never reaches it * Record in okf/servers/jenkins.md the measured traps behind all of it: the ~80 MB log and the stage API that replaces it, the JSON envelope, the 10 KiB tail, HTML-escaped log text, the cascade rule, timestamp-prefixed console lines, empty changeSets on Commons, noreply authors, and the build cadence that makes a blame window 1-17 commits wide * Point xwiki-release-test-triage at the new skill for the acting case * Quote the whole of an error and not its first line: keep the lines that continue each named pattern, and emit a contiguous block as evidence. Maven prints "Rule 0: ... failed with message:" and puts the module, the dependency and the two versions underneath, so the matched line on its own said nothing and every RequireUpperBoundDeps break came back unattributable * Match "Rule N: <class> failed with message" without requiring [ERROR]: Maven writes that message twice and the bare copy, inside the MojoExecutionException it dumps, is the one that survives in the 10 KiB tail — so the tail now classifies without paying for the console page. The looser enforcer alternatives keep [ERROR], since "[INFO] --- enforcer:...:enforce (enforcer-rules)" is printed by every green build * Score blame by what the failure itself names, not only by file overlap: Maven coordinates and xwiki-* module ids from the evidence, matched against a commit's changed paths, and library names matched against its subject line, since a version bump changes a pom and nothing else and only the subject says which library. A subject match yields "likely" and never "certain" * Attribute a Sonar quality gate to nobody — it fails on aggregate metrics, not on a change — and rank it below test-breakage so it stops taking the first deep slot; rank a systematic failure tracked as a flicker above plain breakages, that being the one case the skill has an explicit rule for * File one flicker issue per test class per regression window, naming every branch the test fails on (flickerGroup, alsoOn), instead of one issue per method per branch; require its summary to name the class and every method, since jira-flickers.mjs joins on the "Flickering Test" field first and on class + method in the summary second, so a method in neither is filed again the next morning * Render the paste from the work order (--render-detail), in a fixed section order with fixed wording, leaving one "" line per deep incident for the model to replace. A regression window with no green build reads "failing in every build examined, back to #N - start not established" rather than "since #N", that number being how far the sweep looked and not when the break began * Report which environments a class 1 incident failed on, not only how many * Append a visible footer to every commit comment - a machine wrote it, and a wrong attribution may be ignored - next to the invisible dedupe marker * Log in to Matrix per run instead of storing an access token: matrix.org issues short-lived tokens (the mat_ ones), refreshed continuously inside a client, so one copied into a profile or a routine's secret store is dead within minutes and a 06:00 routine finds it expired every morning. MATRIX_USER_BOT + MATRIX_PASSWORD_BOT log in on a fixed device; MATRIX_TOKEN_BOT is still honoured, for homeservers whose tokens do not expire, and is fallen back from to the password when the server refuses it * Default the room to the fully qualified #xwiki:matrix.xwiki.com and the homeserver to matrix.org: the account and the room are on different servers, and completing a bare alias with the homeserver's own hostname builds #xwiki:matrix.org, which does not exist * Join the room when a send comes back 403, so an invited bot needs nobody to notice, and report a credential failure as a sentence rather than a stack trace - an expired token is this tool's expected failure, not a bug in it * Require a *classic* GitHub token for the bot, and say why in README: the xwiki org rejects a fine-grained token whose lifetime exceeds 366 days, with a 403 on every request including plain reads * Make the local developer run the default mode, the routine's --write the exception: a developer can sweep at any time, and that run analyses to the terminal, never posts the Matrix digest, and asks once before each of the four writes it may make - the PrivateBin paste, a commit comment, a flicker issue, a fix PR. It needs no bot credential to be useful, the sweep, the analysis and the paste all working with nothing configured. An unattended run has nobody to ask, so it writes nothing, which is what makes the dry-run soak safe * Refuse the digest locally whatever the answer: it is the one broadcast here, with no addressee and no undo, and it is the routine's own output - a second one from a laptop at 14:00 turns the room's record of CI into a record of who ran the skill. A locally filed flicker issue cannot duplicate the next morning's run, the routine filing only a proven flicker whose jira is null and that field coming from a live lookup * Carry each channel's identity for its own reason: a comment is the bot's always, since it lands unasked on someone else's commit and must never read as coming from a colleague; a local fix PR is the developer's own, there being no App token on a laptop and a PR being proposed work someone has to own; a local issue is the bot's when JIRA_TOKEN_BOT is set and the developer's otherwise, an unassigned flicker issue being an authorship rather than an accusation * Make every writer tool a no-op without its own --write, inverting --dry-run (still accepted, being what now happens anyway): the bot credentials sit in a developer's shell profile as well as in the routine's secret store, so one forgotten flag was a real comment on a colleague's commit. The safety property is now one sentence with no exception - no tool here writes anywhere unless told to * Drop the fork requirement, which rested on a wrong inference: the bot's token does have push:false on all three repos, but it is not what pushes. The Claude GitHub App installed on the org opens the PR with the head branch in the upstream repo itself, exactly as it already does for the SonarQube routine, and the bot identity rides on the commit author instead (XWiki LLM Bot <llm-bot(a)xwiki.org>) * Add scripts/routine-setup.sh, the setup script a routine's sandbox runs before the prompt: a sandbox is new every run, so gh, the plugin, JDK 17 and 21, xmvn and an ~/.m2/settings.xml pointing at XWiki's Nexus are installed there every time. Keeping it in the repo is what lets a routine be rebuilt from scratch and makes a change to it a reviewed pull request rather than an edit to a config box nobody else can see. xmvn and the two JDKs are what let one sandbox verify a fix on any branch: it reads xwiki.java.version from the pom and exports the matching JAVA_HOME, the maintained branches wanting 17 up to stable-17.10.x and 21 from stable-18.4.x on. Shared with the SonarCloud routine Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> Commit: 8abc00ac5c6970305ba34904db67b79b1ad16481 https://github.com/xwiki/xwiki-dev-llm/commit/8abc00ac5c6970305ba34904db67b… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-17 (Thu, 17 Sep 2026) Changed paths: M README.md M xwiki/okf/index.md M xwiki/okf/servers/jenkins.md M xwiki/scripts/jenkins.mjs A xwiki/scripts/jira-flickers.mjs A xwiki/scripts/routine-setup.sh A xwiki/skills/xwiki-ci-check/SKILL.md A xwiki/skills/xwiki-ci-check/routine-prompt.md A xwiki/skills/xwiki-ci-check/tools/ci-check.mjs A xwiki/skills/xwiki-ci-check/tools/commit-comment.mjs A xwiki/skills/xwiki-ci-check/tools/matrix.mjs A xwiki/skills/xwiki-ci-check/tools/privatebin.mjs M xwiki/skills/xwiki-release-test-triage/SKILL.md M xwiki/skills/xwiki-release-test-triage/tools/triage.mjs Log Message: ----------- Merge pull request #142 from xwiki/ci-check-skill [Misc] Add the xwiki-ci-check skill, the daily acting CI sweep Compare: https://github.com/xwiki/xwiki-dev-llm/compare/1d5332d0601c...8abc00ac5c69 To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-dev-llm/settings/notifications

1 0

[xwiki/xwiki-dev-llm] 5ab961: [Misc] Record the SonarCloud routine's prompt and ...
by XWiki Notifications 17 Sep '26

17 Sep '26

Branch: refs/heads/sonarcloud-routine-prompt Home: https://github.com/xwiki/xwiki-dev-llm Commit: 5ab961b2851fcfde6b3cb8a1134a11ed3b4898a6 https://github.com/xwiki/xwiki-dev-llm/commit/5ab961b2851fcfde6b3cb8a1134a1… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-17 (Thu, 17 Sep 2026) Changed paths: M README.md M xwiki/instructions/xwiki-org.md A xwiki/okf/architecture/platform-modules.md M xwiki/okf/index.md M xwiki/skills/xwiki-build/SKILL.md A xwiki/skills/xwiki-fix-sonarqube-issue/routine-prompt.md Log Message: ----------- [Misc] Record the SonarCloud routine's prompt and environment * Add skills/xwiki-fix-sonarqube-issue/routine-prompt.md: the prompt the scheduled routine is given, plus its variables, checkouts, setup script and memory repo. The routine lives in a config box in the web UI that nobody else can read, review or restore, so a change to it was invisible and a lost routine unrebuildable; recorded here, a change to it is a pull request * Add okf/architecture/platform-modules.md and a pnpm/Nx section to the xwiki-build skill. The prompt carried xwiki-platform's module structure, architecture and frontend facts, which are true for every session in that repo and which nothing made anyone review when they went stale. Two of its claims were in the OKF already and are dropped: never grow oldcore, and the event-listener model, both in component-system.md * Record how the routine's pull requests are opened, that being the thing most easily got wrong by reasoning from a token's permissions: the Claude GitHub App installed on the org pushes the branch into the upstream repo itself, no fork and no personal access token are involved, and the bot identity is carried by the commit author Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-dev-llm/settings/notifications

1 0

[xwiki-contrib/application-changerequest] f93810: CRAPP-437: The creator of a page created through a...
by XWiki Notifications 17 Sep '26

17 Sep '26

Branch: refs/heads/CRAPP-437 Home: https://github.com/xwiki-contrib/application-changerequest Commit: f93810f8585e173c1f538577635dc2fa57691e15 https://github.com/xwiki-contrib/application-changerequest/commit/f93810f85… Author: Simon Urli <simon.urli(a)xwiki.com> Date: 2026-09-17 (Thu, 17 Sep 2026) Changed paths: M application-changerequest-default/src/main/java/org/xwiki/contrib/changerequest/internal/storage/DefaultFileChangeStorageManager.java M application-changerequest-default/src/test/java/org/xwiki/contrib/changerequest/internal/storage/DefaultFileChangeStorageManagerTest.java Log Message: ----------- CRAPP-437: The creator of a page created through a change request is the user who published it, not the user who created it * Set explicitly the original metadata author of a document published from a creation filechange to the author of that filechange, instead of relying on the value surviving the serialization of the stored modified document * Document why the merge of an edition filechange already sets that author the same way * Assert the original metadata author in the unit tests of DefaultFileChangeStorageManager#mergeCreation Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki-contrib/application-changerequest/settings/notific…

1 0

[xwiki/xwiki-dev-llm] 5d54ba: [Misc] Record the SonarCloud routine's prompt and ...
by XWiki Notifications 17 Sep '26

17 Sep '26

Branch: refs/heads/sonarcloud-routine-prompt Home: https://github.com/xwiki/xwiki-dev-llm Commit: 5d54ba4f60e8a25c1ee8cc99e31d1e7d01afaa12 https://github.com/xwiki/xwiki-dev-llm/commit/5d54ba4f60e8a25c1ee8cc99e31d1… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-17 (Thu, 17 Sep 2026) Changed paths: M README.md M xwiki/instructions/xwiki-org.md A xwiki/okf/architecture/platform-modules.md M xwiki/okf/index.md M xwiki/skills/xwiki-build/SKILL.md A xwiki/skills/xwiki-fix-sonarqube-issue/routine-prompt.md Log Message: ----------- [Misc] Record the SonarCloud routine's prompt and environment * Add skills/xwiki-fix-sonarqube-issue/routine-prompt.md: the prompt the scheduled routine is given, plus its variables, checkouts, setup script and memory repo. The routine lives in a config box in the web UI that nobody else can read, review or restore, so a change to it was invisible and a lost routine unrebuildable; recorded here, a change to it is a pull request * Add okf/architecture/platform-modules.md and a pnpm/Nx section to the xwiki-build skill. The prompt carried xwiki-platform's module structure, architecture and frontend facts, which are true for every session in that repo and which nothing made anyone review when they went stale. Two of its claims were in the OKF already and are dropped: never grow oldcore, and the event-listener model, both in component-system.md * Drop SONARQUBE_PROJECT_KEY from the routine's environment: it names one SonarCloud project and the routine sweeps three. Nothing depended on it, the MCP server declaring it optional and resolving the project per workspace; it stays in .mcp.json for the developer case of one checkout, one project * Record how the routine's pull requests are opened, that being the thing most easily got wrong by reasoning from a token's permissions: the Claude GitHub App installed on the org pushes the branch into the upstream repo itself, no fork and no personal access token are involved, and the bot identity is carried by the commit author Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-dev-llm/settings/notifications

1 0

[xwiki/xwiki-dev-llm] 759081: [Misc] Record the SonarCloud routine's prompt and ...
by XWiki Notifications 17 Sep '26

17 Sep '26

Branch: refs/heads/sonarcloud-routine-prompt Home: https://github.com/xwiki/xwiki-dev-llm Commit: 759081684f869f8328460057ba8db2cdb4c3a697 https://github.com/xwiki/xwiki-dev-llm/commit/759081684f869f8328460057ba8db… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-17 (Thu, 17 Sep 2026) Changed paths: M README.md M xwiki/instructions/xwiki-org.md A xwiki/okf/architecture/platform-modules.md M xwiki/okf/index.md M xwiki/skills/xwiki-build/SKILL.md A xwiki/skills/xwiki-fix-sonarqube-issue/routine-prompt.md Log Message: ----------- [Misc] Record the SonarCloud routine's prompt and environment * Add skills/xwiki-fix-sonarqube-issue/routine-prompt.md, the record of the scheduled SonarCloud routine: the prompt verbatim, the variables it is given, the repos it has checked out, the setup script it runs, and the memory repo it reads and writes. The routine lives in a config box in the web UI that nobody else can read, review or restore, so a change to it was invisible and a lost routine unrebuildable; recorded here, a change to it is a pull request. Mirrors what xwiki-ci-check already carries * Record how the routine's pull requests are actually opened, that being the thing most easily got wrong by reasoning from a token's permissions: the Claude GitHub App installed on the org pushes the branch into the upstream repo itself, no fork and no personal access token are involved, and the bot identity is carried by the commit author. GH_TOKEN is the bot's, which the memory repo's own history shows * Point the prompt at the memory repo's new home: it was transferred on 2026-09-17 from vmassol/claude-routine-memory to xwikiorg-llm-bot/sonarcloud-routine-memory, so that the routine's memory belongs to the routine's identity rather than to a person. Both questions the move raised are answered and recorded: GH_TOKEN still pushes, more strongly than before since the bot now owns the repository outright, and the sonarqube/ prefix stays — flattening it would rewrite the paths inside learnings.md's own Rule index and every cross-reference under rules/, which is content churn in the one place whose whole value is that it accumulates. GitHub answers the old path with a redirect, so nothing was broken by the move; the reference is updated anyway, a redirect keeping code running while teaching every later reader the wrong owner * Move the XWiki knowledge out of the prompt and into the plugin, where every session gets it and where it is reviewed when it goes stale: add okf/architecture/platform-modules.md (the tools/core/distribution split, the modules worth knowing by name, the OSGi manifest each JAR carries and what xwiki.extension.features advertises) and a pnpm/Nx section to the xwiki-build skill, that being a build procedure rather than declarative knowledge. Two of the prompt's claims were in the OKF already and are simply dropped: never grow oldcore, and the event-listener model, both in component-system.md and the latter in more detail than the prompt had it * Rewrite the prompt around what is left: the three repositories named once at the top rather than one of them in the first sentence and two in a later bullet, the memory protocol as one block rather than a sentence and two overlapping bullets, dropped-issues.md named rather than "somewhere in the memory files", and "assign it to me" as "assign it to xwikiorg-llm-bot" — a routine has no "me" to resolve the pronoun against, and the work is the bot's, so the bot carries it rather than landing in a person's assigned list nightly. Record how to check an assignee while there: GitHub takes assignees only from the users a repository accepts and drops the rest without an error, so a mistyped name is a PR that is never assigned with nothing anywhere saying so — repos/{owner}/{repo}/assignees/{user} answers 204 or 404, and xwikiorg-llm-bot answers 204 on all three * Drop SONARQUBE_PROJECT_KEY from the routine's environment: it names one SonarCloud project and the routine sweeps three, so any value was wrong for two of them. Nothing depended on it, the MCP server declaring it optional and resolving the project per workspace; it stays in .mcp.json for the developer case of one checkout, one project Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-dev-llm/settings/notifications

1 0

[xwiki/xwiki-commons] 436b01: XCOMMONS-2092: Possible race condition in ReadWrit...
by XWiki Notifications 17 Sep '26

17 Sep '26

Branch: refs/heads/XCOMMONS-2092 Home: https://github.com/xwiki/xwiki-commons Commit: 436b01d4797001e85faaec3192666367b2039c37 https://github.com/xwiki/xwiki-commons/commit/436b01d4797001e85faaec3192666… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-17 (Thu, 17 Sep 2026) Changed paths: M xwiki-commons-core/xwiki-commons-job/xwiki-commons-job-default/src/test/java/org/xwiki/job/internal/DefaultJobExecutorTest.java Log Message: ----------- XCOMMONS-2092: Possible race condition in ReadWriteSemaphore Follow-up to the review of the previous commit: restore every assertion it had removed from DefaultJobExecutorTest, and clear java:S5961 by fixing what actually inflated the count instead. * waitJobState() reported its timeout through fail(), and assertion-aware analysis resolves helper methods transitively, so every waitJobWaiting()/waitJobFinished() call counted as an assertion of the calling test. Each checkpoint of these tests was therefore counted twice: once for the barrier that drives the choreography to its next step, and once for the assertion that states what is expected there. That is what took matchingGroupPathAreBlockedPoolMultiSizeParentFirst to 28 for a method stating 18 expectations. * Raise that timeout by throwing instead. Assertions.fail() is itself a throw of an AssertionError subclass, so behaviour and Surefire reporting are unchanged, and the count now equals the number of expectations each test states: 28 -> 18, 29 -> 17 and 18 -> 12. The java:S5961 suppression added by the previous commit is dropped. * The same helper resolution applies to "tests should include assertions", where the effect is worse: a test whose only assertion-like call is a wait would have looked like it verifies something. It no longer does. * Restore the interrupt flag and keep the InterruptedException as the cause, instead of swallowing both. * Extract the repeated GroupedJobInitializer stubbing into mockPool(poolSize, path...) and mockAllPools(poolSize), so each test opens with the pool sizes its scenario comment describes. * Fix the last assertion of matchingGroupPathAreBlocked, which was on job1 twice instead of job12 and job1. * Fix two comments mangled by a search and replace ("taken into ABcount", "they are ABtually after"). Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-commons/settings/notifications

1 0

[xwiki/xwiki-platform] 9042d3: XWIKI-22942: isSuperAdmin is implemented in many d...
by XWiki Notifications 17 Sep '26

17 Sep '26

Branch: refs/heads/XWIKI-22942 Home: https://github.com/xwiki/xwiki-platform Commit: 9042d3481ee47d448eb3797943fc9a979b3918c8 https://github.com/xwiki/xwiki-platform/commit/9042d3481ee47d448eb3797943fc… Author: Simon Urli <simon.urli(a)xwiki.com> Date: 2026-09-17 (Thu, 17 Sep 2026) Changed paths: M xwiki-platform-core/xwiki-platform-extension/xwiki-platform-extension-handlers/xwiki-platform-extension-handler-xar/src/main/java/org/xwiki/extension/xar/internal/security/XarSecurityTool.java M xwiki-platform-core/xwiki-platform-oldcore/pom.xml M xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/doc/DefaultDocumentAccessBridge.java M xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/internal/plugin/rightsmanager/UserIterator.java M xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/user/api/XWikiRightService.java M xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/user/api/XWikiUser.java M xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/user/impl/xwiki/AbstractXWikiAuthService.java M xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/user/impl/xwiki/AppServerTrustedAuthServiceImpl.java M xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/user/impl/xwiki/AppServerTrustedKerberosAuthServiceImpl.java M xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/user/impl/xwiki/XWikiAuthServiceImpl.java M xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/user/impl/xwiki/XWikiRightServiceImpl.java M xwiki-platform-core/xwiki-platform-oldcore/src/test/java/com/xpn/xwiki/user/impl/xwiki/XWikiAuthServiceImplTest.java M xwiki-platform-core/xwiki-platform-security/xwiki-platform-security-authorization/xwiki-platform-security-authorization-api/pom.xml M xwiki-platform-core/xwiki-platform-security/xwiki-platform-security-authorization/xwiki-platform-security-authorization-api/src/main/java/org/xwiki/security/authorization/AuthorizationManager.java M xwiki-platform-core/xwiki-platform-security/xwiki-platform-security-authorization/xwiki-platform-security-authorization-api/src/test/java/org/xwiki/security/authorization/AbstractAuthorizationTestCase.java M xwiki-platform-core/xwiki-platform-security/xwiki-platform-security-authorization/xwiki-platform-security-authorization-api/src/test/java/org/xwiki/security/authorization/DefaultAuthorizationManagerTest.java M xwiki-platform-core/xwiki-platform-test/xwiki-platform-test-checker/src/main/java/org/xwiki/test/checker/internal/ProgrammingRightCheckerAuthorizationManager.java M xwiki-platform-core/xwiki-platform-user/xwiki-platform-user-api/pom.xml M xwiki-platform-core/xwiki-platform-user/xwiki-platform-user-api/src/main/java/org/xwiki/user/SuperAdminUserReference.java M xwiki-platform-core/xwiki-platform-user/xwiki-platform-user-api/src/test/java/org/xwiki/user/SuperAdminUserReferenceTest.java M xwiki-platform-core/xwiki-platform-user/xwiki-platform-user-default/src/main/java/org/xwiki/user/internal/AbstractUserPropertiesResolver.java M xwiki-platform-core/xwiki-platform-user/xwiki-platform-user-default/src/main/java/org/xwiki/user/internal/DefaultUserManager.java M xwiki-platform-core/xwiki-platform-user/xwiki-platform-user-default/src/main/java/org/xwiki/user/internal/document/AbstractDocumentStringUserReferenceResolver.java M xwiki-platform-core/xwiki-platform-user/xwiki-platform-user-default/src/main/java/org/xwiki/user/internal/document/AbstractUserReferenceResolver.java M xwiki-platform-core/xwiki-platform-user/xwiki-platform-user-default/src/main/java/org/xwiki/user/internal/document/CurrentUserManager.java M xwiki-platform-core/xwiki-platform-user/xwiki-platform-user-default/src/main/java/org/xwiki/user/internal/document/DocumentDocumentReferenceUserReferenceResolver.java M xwiki-platform-core/xwiki-platform-user/xwiki-platform-user-default/src/main/java/org/xwiki/user/internal/document/DocumentDocumentReferenceUserReferenceSerializer.java M xwiki-platform-core/xwiki-platform-user/xwiki-platform-user-default/src/main/java/org/xwiki/user/internal/document/DocumentStringUserReferenceSerializer.java M xwiki-platform-core/xwiki-platform-user/xwiki-platform-user-default/src/main/java/org/xwiki/user/internal/document/UserPreferencesConfigurationSource.java M xwiki-platform-core/xwiki-platform-user/xwiki-platform-user-default/src/test/java/org/xwiki/user/internal/document/DocumentDocumentReferenceUserReferenceResolverTest.java M xwiki-platform-core/xwiki-platform-user/xwiki-platform-user-resource/src/main/java/org/xwiki/user/resource/internal/ConfiguredUserResourceReferenceSerializer.java Log Message: ----------- XWIKI-22942: isSuperAdmin is implemented in many different ways * Make SuperAdminUserReference the single source of truth for the Super Admin user: add SUPERADMIN_USER_NAME, SUPERADMIN_USER_SPACE, SUPERADMIN_LOCAL_REFERENCE, isSuperAdmin(UserReference), isSuperAdminReference(EntityReference) and isSuperAdminName(String) * Only recognize XWiki.superadmin as the Super Admin user, i.e. check the space on top of the name everywhere a reference is available, and resolve a user document named superadmin outside of the XWiki space as an ordinary user reference * Make AuthorizationManager, XWikiRightService, XWikiUser, UserIterator, DefaultDocumentAccessBridge, AbstractXWikiAuthService, XWikiRightServiceImpl and the user reference resolvers and serializers all rely on SuperAdminUserReference rather than on their own comparison * Add AuthorizationManager#isSuperAdmin(UserReference) * Deprecate XWikiRightService#isSuperAdmin(EntityReference) * Resolve the user reference in ProgrammingRightCheckerAuthorizationManager rather than comparing it to InternalTemplateManager#SUPERADMIN_REFERENCE * Keep the name only rule for the authentication services, which compare a name resolved with the default document reference resolver * Check the superadmin name against the user name XWikiAuthServiceImpl actually looks up, which is not parsed out of the entered string the same way as the name the existing check compares * Do not take the superadmin user name from the application server in the trusted authentication services Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-platform/settings/notifications

1 0