September 2026 - notifications

[xwiki/xwiki-dev-llm] 430e9b: Say where a release-note screenshot comes from, an...
by XWiki Notifications 10 Sep '26

10 Sep '26

Branch: refs/heads/release-documentation-skill Home: https://github.com/xwiki/xwiki-dev-llm Commit: 430e9bcbfbba52e98391cf10ad73a9db2ddac344 https://github.com/xwiki/xwiki-dev-llm/commit/430e9bcbfbba52e98391cf10ad73a… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-10 (Thu, 10 Sep 2026) Changed paths: M xwiki/okf/processes/release-notes.md M xwiki/skills/xwiki-release-documentation/SKILL.md Log Message: ----------- Say where a release-note screenshot comes from, and file RN-119 for the missing PUT A change about something visible in the UI is expected to carry a screenshot, and the skill said only that one gets attached, which leaves an author free to shoot a fresh one. Two screenshots of the same feature taken at different moments disagree about width, theme, sample data and what is hovered, so the release note would illustrate something subtly unlike the documentation it links. * Record in the OKF that the screenshot is produced for the reference documentation first and the release note reuses that exact image, never its own. * Record that it is copied onto the entry page rather than linked to the documentation page. A release note is the record of one moment: when the documentation screenshot is refreshed for a later UI, every past release note must still show the UI as it was at that release, and a link would silently rewrite what old release notes claim. * Make §6.1 run before §6.2 for such a change in the skill, since that is where the image is made, and spell out the copy as a download-then-upload against the page the POST returned. * Flag, rather than derive, the screenshots of a UI-visible change whose documentation verdict was N/A: it has no image to reuse, which usually means the verdict is wrong. * Reference RN-119, filed for the missing PUT endpoint that forces the property to be written through the generic object API. 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-platform] 000c47: XWIKI-24796: Live Data fails to render in PDF expo...
by XWiki Notifications 10 Sep '26

10 Sep '26

Branch: refs/heads/master Home: https://github.com/xwiki/xwiki-platform Commit: 000c476f756be900452e981f3199c96c683808d8 https://github.com/xwiki/xwiki-platform/commit/000c476f756be900452e981f3199… Author: LucasC <lucas.charpentier(a)xwiki.com> Date: 2026-09-10 (Thu, 10 Sep 2026) Changed paths: M xwiki-platform-core/xwiki-platform-dashboard/xwiki-platform-dashboard-ui/src/main/resources/Dashboard/XWikiUserDashboardSheet.xml M xwiki-platform-core/xwiki-platform-notifications/xwiki-platform-notifications-ui/src/main/resources/XWiki/Notifications/Code/XWikiUserNotificationsSheet.xml Log Message: ----------- XWIKI-24796: Live Data fails to render in PDF export on 17.10.x (#6361) * Removed the trailing whitespace between {{/velocity}} and </content> in the executed content of the Dashboard.XWikiUserDashboardSheet and XWiki.Notifications.Code.XWikiUserNotificationsSheet UI extensions. That indentation is outside the Velocity macro, so nothing gobbles it: it survived as a text node after the last block, and the renderer therefore wrapped the whole pane content, the block level elements included, in a single paragraph. This is what made the HTML5 validation of the user profile fail once these UI extensions stopped being rendered through a cleaning {{html}} macro. Co-authored-by: Claude Opus 5 <noreply(a)anthropic.com> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-platform/settings/notifications

1 0

[xwiki/xwiki-platform] c13cda: XWIKI-24808: The Live Data is not always rendered ...
by XWiki Notifications 10 Sep '26

10 Sep '26

Branch: refs/heads/stable-17.10.x Home: https://github.com/xwiki/xwiki-platform Commit: c13cda383d160dd2995b4f0f4326d102dd319b6a https://github.com/xwiki/xwiki-platform/commit/c13cda383d160dd2995b4f0f4326… Author: Marius Dumitru Florea <marius(a)xwiki.com> Date: 2026-09-10 (Thu, 10 Sep 2026) Changed paths: M xwiki-platform-core/xwiki-platform-export/xwiki-platform-export-pdf/xwiki-platform-export-pdf-test/xwiki-platform-export-pdf-test-docker/pom.xml M xwiki-platform-core/xwiki-platform-export/xwiki-platform-export-pdf/xwiki-platform-export-pdf-test/xwiki-platform-export-pdf-test-docker/src/test/it/org/xwiki/export/pdf/test/ui/PDFExportIT.java A xwiki-platform-core/xwiki-platform-livedata/xwiki-platform-livedata-webjar/src/main/node/src/components/XWikiLivedata.test.js M xwiki-platform-core/xwiki-platform-livedata/xwiki-platform-livedata-webjar/src/main/node/src/components/XWikiLivedata.vue M xwiki-platform-core/xwiki-platform-livedata/xwiki-platform-livedata-webjar/src/main/node/src/components/layouts/LivedataLayout.test.js M xwiki-platform-core/xwiki-platform-livedata/xwiki-platform-livedata-webjar/src/main/node/src/components/layouts/LivedataLayout.vue M xwiki-platform-core/xwiki-platform-livedata/xwiki-platform-livedata-webjar/src/main/node/src/main.js M xwiki-platform-core/xwiki-platform-livedata/xwiki-platform-livedata-webjar/src/main/node/src/services/logic.js Log Message: ----------- XWIKI-24808: The Live Data is not always rendered in the PDF export (#6331) * Delay the page ready detection until the Live Data is fully displayed: the user interface is loaded with dynamic imports and the entries are fetched asynchronously, neither of which the page ready detection can see. * Trigger a new "instanceReady" event, on the Live Data logic, once the layout is loaded and the entries are displayed (or as soon as we know that neither is coming), and return a promise settled by this event from the Live Data initialization, so that the page ready detection has something to wait for. The event data holds the error that prevented the display, if any, so that the listeners can tell success from failure, and the returned promise is rejected with it. * Trigger the "layoutLoaded" event also when no layout can be loaded at all (the requested one failed and there's no usable default layout to fall back on), with the error in the event data, so that the listeners waiting for a layout don't wait indefinitely. This also unblocks the layout loading indicator, which was left running when a layout change failed. * Wait for the displayers to be preloaded and for the DOM to be updated before triggering "entriesUpdated", by awaiting the preload promise and the next tick inside the entries update chain, instead of leaving them in a detached promise chain. * Add component tests for the new "instanceReady" and "layoutLoaded" behavior, covering both the success and the failure paths. * Add a functional test that checks the PDF export of the Live Data macro, verifying that the entries are fetched and that the sort, filter and page size set by the user are preserved. * Fix the Live Table PDF export test, whose Location filter value also matched the new Live Data test page. * Adapt the change to this branch, where the Live Data user interface is still part of the webjar and where the initialization is done by the Live Data logic constructor rather than by the root component: the page ready is delayed in the webjar entry point, using the "instanceReady" event triggered on the Live Data element, and the root component waits for the first entries through a promise exposed by the logic. Co-authored-by: Claude Opus 5 (1M context) <noreply(a)anthropic.com> (cherry picked from commit 1f514255f091521262cef4b2f0908a7f0971596c) Commit: ad2bd3c33bc0712468b0b177004ea82587069622 https://github.com/xwiki/xwiki-platform/commit/ad2bd3c33bc0712468b0b177004e… Author: Marius Dumitru Florea <marius(a)xwiki.com> Date: 2026-09-10 (Thu, 10 Sep 2026) Changed paths: M xwiki-platform-core/xwiki-platform-livedata/xwiki-platform-livedata-test/xwiki-platform-livedata-test-docker/src/test/it/org/xwiki/livedata/test/ui/LiveDataIT.java Log Message: ----------- [Misc] Fix LiveDataIT#livedataLivetableTableLayout failing on the Live Data cell actions popover * Select the "isActive" filter suggestions with the keyboard, because clicking on them leaves the mouse pointer over a table cell, whose cell actions popover then covers the suggestions and intercepts the next click. Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> Commit: 76f84a0117c5fbc7de8e6477706259e6583be4a3 https://github.com/xwiki/xwiki-platform/commit/76f84a0117c5fbc7de8e64777062… Author: Marius Dumitru Florea <marius(a)xwiki.com> Date: 2026-09-10 (Thu, 10 Sep 2026) Changed paths: M xwiki-platform-core/xwiki-platform-livedata/xwiki-platform-livedata-macro/src/main/resources/templates/liveData/importmap.vm Log Message: ----------- XWIKI-24796: Live Data fails to render in PDF export on 17.10.x * Force HTML rendering of the UI extension. Compare: https://github.com/xwiki/xwiki-platform/compare/85e36d896f01...76f84a0117c5 To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-platform/settings/notifications

1 0

[[email protected]][Issue] Updates for XWIKI-24863: Update dependency org.webjars.npm:moment-timezone to v0.6.3
by XWiki Notifications 10 Sep '26

10 Sep '26

1 0

[xwiki/xwiki-platform] a217cd: XWIKI-24863: Update dependency org.webjars.npm:mom...
by XWiki Notifications 10 Sep '26

10 Sep '26

Branch: refs/heads/master Home: https://github.com/xwiki/xwiki-platform Commit: a217cda149389ffcefb83e8e3d779b6aa5c61a93 https://github.com/xwiki/xwiki-platform/commit/a217cda149389ffcefb83e8e3d77… Author: Mend Renovate <bot(a)renovateapp.com> Date: 2026-09-10 (Thu, 10 Sep 2026) Changed paths: M xwiki-platform-core/xwiki-platform-flamingo/xwiki-platform-flamingo-skin/xwiki-platform-flamingo-skin-resources/pom.xml Log Message: ----------- XWIKI-24863: Update dependency org.webjars.npm:moment-timezone to v0.6.3 (#6351) To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-platform/settings/notifications

1 0

[[email protected]][Issue] Updates for XCOMMONS-3481: Stop using http client 3 in the build
by XWiki Notifications 10 Sep '26

10 Sep '26

1 0

[[email protected]][Issue] Updates for XWIKI-24639: In a docker test allow easily switch to browser or http client as default access
by XWiki Notifications 10 Sep '26

10 Sep '26

1 0

[xwiki/xwiki-commons] 87d141: XCOMMONS-2092: Fix the real root cause: a concurre...
by XWiki Notifications 10 Sep '26

10 Sep '26

Branch: refs/heads/XCOMMONS-2092 Home: https://github.com/xwiki/xwiki-commons Commit: 87d141e0e5838431fece272f9f77aca5eb594deb https://github.com/xwiki/xwiki-commons/commit/87d141e0e5838431fece272f9f77a… Author: Simon Urli <simon.urli(a)xwiki.com> Date: 2026-09-10 (Thu, 10 Sep 2026) Changed paths: M xwiki-commons-core/xwiki-commons-job/xwiki-commons-job-default/src/main/java/org/xwiki/job/internal/ReadWriteSemaphore.java M xwiki-commons-core/xwiki-commons-job/xwiki-commons-job-default/src/test/java/org/xwiki/job/internal/DefaultJobExecutorTest.java Log Message: ----------- XCOMMONS-2092: Fix the real root cause: a concurrency bug in ReadWriteSemaphore The previous commit worked around the flicker with a Thread.sleep in the test, but that only narrowed one particular timing window instead of fixing the actual bug. This replaces it with a fix in production code and removes the workaround, which is no longer needed. * ReadWriteSemaphore#lockWrite/unlockWrite/lockRead/unlockRead mutated writeCounter/readCounter with incrementAndGet()/decrementAndGet() and then made the permits decision from a separate, later get() call, letting concurrent callers race and compute the wrong number of permits to acquire or release; a stress test hammering the same parent/child pool shape as the flaky test (pool sizes 1 and 2) reliably deadlocked within a couple hundred operations because of this * Guard the counter mutation and the resulting permit-count decision with an internal lock so each call makes its decision atomically; the lock is released before the (possibly blocking) semaphore acquire/release, so a thread waiting for a permit never holds a lock another thread needs in order to release one * Revert the Thread.sleep workaround added in the previous commit: it is no longer necessary with the real fix in place * Verified with a stress test reproducing the deadlock against the original code and confirming it cannot reproduce against the fix (5 runs x 3M operations each, no failure), and 500 repetitions of every test in DefaultJobExecutorTest (1500 runs total, 0 failures) Co-Authored-By: Claude Sonnet 5 <noreply(a)anthropic.com> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-commons/settings/notifications

1 0

[[email protected]][Issue] Updates for XCOMMONS-3481: Stop using http client 3 in the build
by XWiki Notifications 10 Sep '26

10 Sep '26

1 0

[xwiki/xwiki-commons] 554715: XCOMMONS-3481: Stop using http client 3 in the build
by XWiki Notifications 10 Sep '26

10 Sep '26

Branch: refs/heads/master Home: https://github.com/xwiki/xwiki-commons Commit: 554715ecfa7006757d5603731ba5fdb477c3d4ae https://github.com/xwiki/xwiki-commons/commit/554715ecfa7006757d5603731ba5f… Author: Thomas Mortagne <thomas.mortagne(a)gmail.com> Date: 2025-12-02 (Tue, 02 Dec 2025) Changed paths: M pom.xml Log Message: ----------- XCOMMONS-3481: Stop using http client 3 in the build Commit: fd1930b6456bab0d6021d2e0f583b823bbd5c2a5 https://github.com/xwiki/xwiki-commons/commit/fd1930b6456bab0d6021d2e0f583b… Author: Thomas Mortagne <thomas.mortagne(a)gmail.com> Date: 2026-09-10 (Thu, 10 Sep 2026) Changed paths: M pom.xml Log Message: ----------- Merge pull request #1548 from xwiki/feature-removehttpclient3-test XCOMMONS-3481: Stop using http client 3 in the build Compare: https://github.com/xwiki/xwiki-commons/compare/328e6f8e39a7...fd1930b6456b To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-commons/settings/notifications

1 0