- notifications - lists.xwiki.org

[xwiki-contrib/application-releasenotes] 8fa94c: RN-95: The Release Changes Live Data of the home p...
by XWiki Notifications 31 Aug '26

31 Aug '26

Branch: refs/heads/RN-95 Home: https://github.com/xwiki-contrib/application-releasenotes Commit: 8fa94c4c6825fecad763177ba9f848f83cf009d6 https://github.com/xwiki-contrib/application-releasenotes/commit/8fa94c4c68… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-08-31 (Mon, 31 Aug 2026) Changed paths: M application-releasenotes-ui/pom.xml M application-releasenotes-ui/src/main/resources/ReleaseNotes/Code/HomeReleaseChanges.xml A application-releasenotes-ui/src/test/java/org/xwiki/releasenotes/HomeReleaseChangesPageTest.java Log Message: ----------- RN-95: The Release Changes Live Data of the home page is not sorted by creation date any more * Sort the "Release Changes" Live Data of the application home page on the creation date, most recent change first, which is what a reader of that list looks for. The liveData macro applies no sort of its own, unlike the #livetable macro it replaced in RN-75, which selected the first non special column of its column list, i.e. the creation date. Since that conversion the list has been returning its rows in whatever order the database gave them: the results page adds no "order by" clause at all when it is given no sort. * Sort on the creation date although its column is not displayed: only the display of a column is hidden, the property stays part of the query and can be sorted on. * Add a page test asserting the sort in the configuration that the macro hands to Live Data. Asserting the order of the displayed rows instead would prove nothing: without an "order by" the rows can come back in the expected order anyway, and a functional test written that way passed with the sort parameter removed. 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

[[email protected]][Issue] Updates for RN-87: Version range filters in getChanges compare versions as strings
by XWiki Notifications 31 Aug '26

31 Aug '26

1 0

[xwiki-contrib/application-releasenotes]
by XWiki Notifications 31 Aug '26

31 Aug '26

Branch: refs/heads/RN-87 Home: https://github.com/xwiki-contrib/application-releasenotes 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/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