- notifications - lists.xwiki.org

[xwiki-contrib/application-releasenotes] 71a37b: RN-87: Version range filters in getChanges compare...
by XWiki Notifications 31 Aug '26

31 Aug '26

Branch: refs/heads/master Home: https://github.com/xwiki-contrib/application-releasenotes Commit: 71a37b6a526ecbcee1cc3e4fdb8d0f1b0b136ffe https://github.com/xwiki-contrib/application-releasenotes/commit/71a37b6a52… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-08-31 (Mon, 31 Aug 2026) Changed paths: M application-releasenotes-test/application-releasenotes-test-docker/src/test/it/org/xwiki/releasenotes/test/ui/ReleaseNotesIT.java M application-releasenotes-ui/pom.xml M application-releasenotes-ui/src/main/resources/ReleaseNotes/Code/Change/GetChangesMacro.xml M application-releasenotes-ui/src/test/java/org/xwiki/releasenotes/GetChangesMacroPageTest.java Log Message: ----------- RN-87: Version range filters in getChanges compare versions as strings * Resolve each version comparison filter of the getChanges macro into the explicit list of the versions the wiki holds, compared with the extension version scheme ($services.extension.parseVersion, the Maven ordering) instead of letting the database compare the VARCHAR column, which sorted 10.0 before 9.0 * Read those versions from the release notes rather than from the entries, since a query may only select documents: selecting a property value needs programming right, which this application does not require * Test a resolved version with an "=" filter prefix, which the macro now also accepts from its callers * Generate a clause matching nothing instead of an empty, and thus invalid, "()" when a filter resolves to no item * Describe the versions macro parameter * Cover the resolution in GetChangesMacroPageTest, and the whole chain in ReleaseNotesIT Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> Commit: 82eef44ed0541085b35cdbb616d679fc279a674c https://github.com/xwiki-contrib/application-releasenotes/commit/82eef44ed0… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-08-31 (Mon, 31 Aug 2026) Changed paths: M application-releasenotes-test/application-releasenotes-test-docker/src/test/it/org/xwiki/releasenotes/test/ui/ReleaseNotesIT.java M application-releasenotes-ui/pom.xml M application-releasenotes-ui/src/main/resources/ReleaseNotes/Code/Change/GetChangesMacro.xml M application-releasenotes-ui/src/test/java/org/xwiki/releasenotes/GetChangesMacroPageTest.java Log Message: ----------- RN-87: Version range filters in getChanges compare versions as strings Compare: https://github.com/xwiki-contrib/application-releasenotes/compare/a14fed408… To unsubscribe from these emails, change your notification settings at https://github.com/xwiki-contrib/application-releasenotes/settings/notifica…

1 0

[xwiki-contrib/application-releasenotes] 71a37b: RN-87: Version range filters in getChanges compare...
by XWiki Notifications 31 Aug '26

31 Aug '26

Branch: refs/heads/RN-87 Home: https://github.com/xwiki-contrib/application-releasenotes Commit: 71a37b6a526ecbcee1cc3e4fdb8d0f1b0b136ffe https://github.com/xwiki-contrib/application-releasenotes/commit/71a37b6a52… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-08-31 (Mon, 31 Aug 2026) Changed paths: M application-releasenotes-test/application-releasenotes-test-docker/src/test/it/org/xwiki/releasenotes/test/ui/ReleaseNotesIT.java M application-releasenotes-ui/pom.xml M application-releasenotes-ui/src/main/resources/ReleaseNotes/Code/Change/GetChangesMacro.xml M application-releasenotes-ui/src/test/java/org/xwiki/releasenotes/GetChangesMacroPageTest.java Log Message: ----------- RN-87: Version range filters in getChanges compare versions as strings * Resolve each version comparison filter of the getChanges macro into the explicit list of the versions the wiki holds, compared with the extension version scheme ($services.extension.parseVersion, the Maven ordering) instead of letting the database compare the VARCHAR column, which sorted 10.0 before 9.0 * Read those versions from the release notes rather than from the entries, since a query may only select documents: selecting a property value needs programming right, which this application does not require * Test a resolved version with an "=" filter prefix, which the macro now also accepts from its callers * Generate a clause matching nothing instead of an empty, and thus invalid, "()" when a filter resolves to no item * Describe the versions macro parameter * Cover the resolution in GetChangesMacroPageTest, and the whole chain in ReleaseNotesIT 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-releasenotes/settings/notifica…

1 0

[xwiki-contrib/application-releasenotes] fd38cc: RN-87: Version range filters in getChanges compare...
by XWiki Notifications 31 Aug '26

31 Aug '26

Branch: refs/heads/RN-87 Home: https://github.com/xwiki-contrib/application-releasenotes Commit: fd38cc8ccced0b22a3f80ef06f0dfa99c88670ae https://github.com/xwiki-contrib/application-releasenotes/commit/fd38cc8ccc… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-08-31 (Mon, 31 Aug 2026) Changed paths: M application-releasenotes-test/application-releasenotes-test-docker/src/test/it/org/xwiki/releasenotes/test/ui/ReleaseNotesIT.java M application-releasenotes-ui/pom.xml M application-releasenotes-ui/src/main/resources/ReleaseNotes/Code/Change/GetChangesMacro.xml M application-releasenotes-ui/src/test/java/org/xwiki/releasenotes/GetChangesMacroPageTest.java Log Message: ----------- RN-87: Version range filters in getChanges compare versions as strings * Resolve each version comparison filter of the getChanges macro into the explicit list of the versions the wiki holds, compared with the extension version scheme ($services.extension.parseVersion, the Maven ordering) instead of letting the database compare the VARCHAR column, which sorted 10.0 before 9.0 * Read those versions from the release notes rather than from the entries, since a query may only select documents: selecting a property value needs programming right, which this application does not require * Test a resolved version with an "=" filter prefix, which the macro now also accepts from its callers * Generate a clause matching nothing instead of an empty, and thus invalid, "()" when a filter resolves to no item * Describe the versions macro parameter * Cover the resolution in GetChangesMacroPageTest, and the whole chain in ReleaseNotesIT 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-releasenotes/settings/notifica…

1 0

[xwiki-contrib/application-releasenotes] f235fc: RN-90: Twelve pages hardcode the ReleaseNotes spac...
by XWiki Notifications 31 Aug '26

31 Aug '26

Branch: refs/heads/RN-90 Home: https://github.com/xwiki-contrib/application-releasenotes Commit: f235fcd873c87102f7dd607987fa09abc2807a01 https://github.com/xwiki-contrib/application-releasenotes/commit/f235fcd873… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-08-31 (Mon, 31 Aug 2026) Changed paths: M application-releasenotes-ui/src/main/resources/ReleaseNotes/Code/Change/ChangeDisplayerFlow.xml M application-releasenotes-ui/src/main/resources/ReleaseNotes/Code/Change/ChangeDisplayerGrid.xml M application-releasenotes-ui/src/main/resources/ReleaseNotes/Code/Change/ChangeDisplayerList.xml M application-releasenotes-ui/src/main/resources/ReleaseNotes/Code/Change/ChangeDisplayerSimple.xml M application-releasenotes-ui/src/main/resources/ReleaseNotes/Code/Change/ChangeSheet.xml M application-releasenotes-ui/src/main/resources/ReleaseNotes/Code/Change/DisplayChangesMacro.xml M application-releasenotes-ui/src/main/resources/ReleaseNotes/Code/Change/GetChangesMacro.xml M application-releasenotes-ui/src/main/resources/ReleaseNotes/Code/Change/ReleaseNotesChangesMacro.xml M application-releasenotes-ui/src/main/resources/ReleaseNotes/Code/HomeCustomReport.xml M application-releasenotes-ui/src/main/resources/ReleaseNotes/Code/HomeReleaseChanges.xml M application-releasenotes-ui/src/main/resources/ReleaseNotes/Code/HomeReleaseNotes.xml M application-releasenotes-ui/src/main/resources/ReleaseNotes/Code/ReleaseNotesContributorsMacro.xml M application-releasenotes-ui/src/main/resources/ReleaseNotes/Data/WebHome.xml M application-releasenotes-ui/src/main/resources/ReleaseNotes/WebHome.xml A application-releasenotes-ui/src/test/java/org/xwiki/releasenotes/CopiedApplicationPageTest.java A application-releasenotes-ui/src/test/java/org/xwiki/releasenotes/HardcodedTopSpaceTest.java Log Message: ----------- RN-90: Twelve pages hardcode the ReleaseNotes space prefix instead of resolving the top-level space at runtime * Resolve the include target from $topSpace in the twelve places that wrote the literal prefix: ReleaseNotes.WebHome, ReleaseNotes.Data.WebHome (three includes), Code/HomeReleaseNotes, Code/HomeReleaseChanges, Code/Change/ReleaseNotesChangesMacro, the four Code/Change/ChangeDisplayer* pages and Code/Change/ChangeSheet. Each of these includes now sits inside a {{velocity}} block, which is what lets its reference be interpolated, the way Code/Change/DisplayChangesMacro already did. * Resolve the classname of the seven Live Data suggest URLs from $topSpace, in the parse=1 JavaScriptExtension objects of Code/HomeReleaseNotes and Code/HomeCustomReport. They silently suggested nothing in a copy of the application, because the suggest endpoint answers an unknown class with an empty list rather than an error. * State which document resolves $topSpace, which was left unstated: the macro's own document for getChanges and displayChanges, which are callable from any page of the wiki; $doc for releasenotechanges and releasenotecontributors, which only work on a release note page; and the value inherited from displayChanges for the four displayer pages, which now list $topSpace among their documented inputs instead of re-deriving it from the calling page. * Add HardcodedTopSpaceTest, which guards every page content and every parse=1 script extension against the literal prefix, and CopiedApplicationPageTest, which renders displayChanges from a copy of the application under another top-level space with nothing left under the shipped one. 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-releasenotes/settings/notifica…

1 0

[xwiki/xwiki-dev-llm]
by XWiki Notifications 31 Aug '26

31 Aug '26

Branch: refs/heads/okf-wiki-application-data 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] af5589: [Misc] Add an OKF topic for stored data in a wiki ...
by XWiki Notifications 31 Aug '26

31 Aug '26

Branch: refs/heads/master Home: https://github.com/xwiki/xwiki-dev-llm Commit: af5589c0f04afbd38067da7591e9ce80d6b490f6 https://github.com/xwiki/xwiki-dev-llm/commit/af5589c0f04afbd38067da7591e9c… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-08-31 (Mon, 31 Aug 2026) Changed paths: M .claude-plugin/marketplace.json M kimi.plugin.json M opencode.jsonc M xwiki/.claude-plugin/plugin.json M xwiki/instructions/xwiki-org.md A xwiki/okf/architecture/wiki-application-data.md M xwiki/okf/conventions/frontend.md M xwiki/okf/index.md M xwiki/skills/xwiki-review/SKILL.md Log Message: ----------- [Misc] Add an OKF topic for stored data in a wiki application * New `okf/architecture/wiki-application-data.md`. Three traps that a review of a real XClass+wiki-page application hit, none of which had an OKF home: - A list property that is neither `multiSelect` nor large storage is stored as a `StringProperty` (`ListClass.newProperty`) in `xwikistrings.XWS_VALUE`, a VARCHAR, so HQL/XWQL range filters on it compare text. Single-character codes sort as intended, which is what hides it until values differ in length. - A generated `Entry001` name derived from the pages that already exist races for the whole editing session, because the page appears only on save. - A wiki-page migration is idempotent for free if it drops the object it matched on; what it still needs is a completion count. Plus the entry-template trap: a template missing the marker class its queries use produces entries invisible to every query. * Grounded in platform source (`ListClass`, `xwiki.hbm.xml`), verified rather than extrapolated from the one application reviewed. * Cross-reference `[[performance]]` for bounding the migration instead of restating its pagination rule, so the batching rule keeps one home. * `okf/conventions/frontend.md`: the WCAG 2.2 AA bullet stated the commitment but no operational rule, so add the three traps for markup emitted from a wiki page — naming a control (a `<dt>` term and a prompt in `value` are not names, and a prompt in `value` also submits as data), `[[image:]]` alt text defaulting to the filename, and `col-xs-*` not being a responsive layout. Accessibility already lives here, so this extends that entry rather than adding a second home. * `skills/xwiki-review`: stop the accessibility brief asserting a WCAG version of its own. It claimed the OKF had no accessibility topic and named WCAG 2.1, while `frontend.md` has covered accessibility at 2.2 — so a reviewer was being told to cite criteria against a standard the project does not hold. It now reads the level from `frontend.md` and is told never to state it from memory, which is what keeps it from drifting again on the next re-commit. * `skills/xwiki-review`: the data & migration angle claimed the stored-data rules had no OKF home, which this commit makes false, and its routing fired only on `*.hbm.xml`, migrator classes, Solr schema and store code — so it could never run on a XAR-only extension, the very place the new topic applies. Add the XClass / generated-name / wiki-page-migration trigger and cite the new file; narrow the remaining skill-owned marker to Java store and mapping changes. * Describe both OKF changes in `okf/index.md`; add the topic name only to the always-on map in `instructions/xwiki-org.md` (+1 line, routing only). * Bump the plugin version so installed plugins pull the change. Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> Commit: 2cbc3577e39832532172c606a224d9d2dfe54b15 https://github.com/xwiki/xwiki-dev-llm/commit/2cbc3577e39832532172c606a224d… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-08-31 (Mon, 31 Aug 2026) Changed paths: M .claude-plugin/marketplace.json M kimi.plugin.json M opencode.jsonc M xwiki/.claude-plugin/plugin.json M xwiki/instructions/xwiki-org.md A xwiki/okf/architecture/wiki-application-data.md M xwiki/okf/conventions/frontend.md M xwiki/okf/index.md M xwiki/skills/xwiki-review/SKILL.md Log Message: ----------- [Misc] Add an OKF topic for stored data in a wiki application Compare: https://github.com/xwiki/xwiki-dev-llm/compare/79dd0e576832...2cbc3577e398 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] af5589: [Misc] Add an OKF topic for stored data in a wiki ...
by XWiki Notifications 31 Aug '26

31 Aug '26

Branch: refs/heads/okf-wiki-application-data Home: https://github.com/xwiki/xwiki-dev-llm Commit: af5589c0f04afbd38067da7591e9ce80d6b490f6 https://github.com/xwiki/xwiki-dev-llm/commit/af5589c0f04afbd38067da7591e9c… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-08-31 (Mon, 31 Aug 2026) Changed paths: M .claude-plugin/marketplace.json M kimi.plugin.json M opencode.jsonc M xwiki/.claude-plugin/plugin.json M xwiki/instructions/xwiki-org.md A xwiki/okf/architecture/wiki-application-data.md M xwiki/okf/conventions/frontend.md M xwiki/okf/index.md M xwiki/skills/xwiki-review/SKILL.md Log Message: ----------- [Misc] Add an OKF topic for stored data in a wiki application * New `okf/architecture/wiki-application-data.md`. Three traps that a review of a real XClass+wiki-page application hit, none of which had an OKF home: - A list property that is neither `multiSelect` nor large storage is stored as a `StringProperty` (`ListClass.newProperty`) in `xwikistrings.XWS_VALUE`, a VARCHAR, so HQL/XWQL range filters on it compare text. Single-character codes sort as intended, which is what hides it until values differ in length. - A generated `Entry001` name derived from the pages that already exist races for the whole editing session, because the page appears only on save. - A wiki-page migration is idempotent for free if it drops the object it matched on; what it still needs is a completion count. Plus the entry-template trap: a template missing the marker class its queries use produces entries invisible to every query. * Grounded in platform source (`ListClass`, `xwiki.hbm.xml`), verified rather than extrapolated from the one application reviewed. * Cross-reference `[[performance]]` for bounding the migration instead of restating its pagination rule, so the batching rule keeps one home. * `okf/conventions/frontend.md`: the WCAG 2.2 AA bullet stated the commitment but no operational rule, so add the three traps for markup emitted from a wiki page — naming a control (a `<dt>` term and a prompt in `value` are not names, and a prompt in `value` also submits as data), `[[image:]]` alt text defaulting to the filename, and `col-xs-*` not being a responsive layout. Accessibility already lives here, so this extends that entry rather than adding a second home. * `skills/xwiki-review`: stop the accessibility brief asserting a WCAG version of its own. It claimed the OKF had no accessibility topic and named WCAG 2.1, while `frontend.md` has covered accessibility at 2.2 — so a reviewer was being told to cite criteria against a standard the project does not hold. It now reads the level from `frontend.md` and is told never to state it from memory, which is what keeps it from drifting again on the next re-commit. * `skills/xwiki-review`: the data & migration angle claimed the stored-data rules had no OKF home, which this commit makes false, and its routing fired only on `*.hbm.xml`, migrator classes, Solr schema and store code — so it could never run on a XAR-only extension, the very place the new topic applies. Add the XClass / generated-name / wiki-page-migration trigger and cite the new file; narrow the remaining skill-owned marker to Java store and mapping changes. * Describe both OKF changes in `okf/index.md`; add the topic name only to the always-on map in `instructions/xwiki-org.md` (+1 line, routing only). * Bump the plugin version so installed plugins pull the change. 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

[jira@xwiki.org][Issue] Updates for RN-95: The Release Changes Live Data of the home page is not sorted by creation date any more
by XWiki Notifications 31 Aug '26

31 Aug '26

1 0

[jira@xwiki.org][Issue] Updates for RN-90: Twelve pages hardcode the ReleaseNotes space prefix instead of resolving the top-level space at runtime
by XWiki Notifications 31 Aug '26

31 Aug '26

1 0

[jira@xwiki.org][Issue] Updates for RN-91: The contributors functional test saves without waiting for the asynchronous save to complete
by XWiki Notifications 31 Aug '26

31 Aug '26

1 0