Branch: refs/heads/XWIKI-24831 Home: https://github.com/xwiki/xwiki-platform Commit: f8d4ad64975001f6b2d85ac25af9672e52014b85 https://github.com/xwiki/xwiki-platform/commit/f8d4ad64975001f6b2d85ac25af96... Author: Manuel Leduc <[email protected]> Date: 2026-09-09 (Wed, 09 Sep 2026) Changed paths: M pnpm-lock.yaml M pnpm-workspace.yaml M xwiki-platform-core/pom.xml A xwiki-platform-core/xwiki-platform-records/pom.xml A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-macro/pom.xml A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-macro/src/main/java/org/xwiki/records/internal/macro/RecordsMacro.java A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-macro/src/main/java/org/xwiki/records/macro/RecordsColumns.java A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-macro/src/main/java/org/xwiki/records/macro/RecordsDataType.java A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-macro/src/main/java/org/xwiki/records/macro/RecordsMacroParameters.java A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-macro/src/main/resources/ApplicationResources.properties A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-macro/src/main/resources/META-INF/components.txt A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-macro/src/main/resources/templates/html_displayer/recordscolumns/edit.vm A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-macro/src/main/resources/templates/html_displayer/recordsdatatype/edit.vm A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-macro/src/test/java/org/xwiki/records/internal/macro/RecordsMacroTest.java A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-webjar/pom.xml A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-webjar/src/main/node/eslint.config.ts A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-webjar/src/main/node/package.json A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-webjar/src/main/node/src/__tests__/dialog.test.ts A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-webjar/src/main/node/src/__tests__/fieldPicker.test.ts A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-webjar/src/main/node/src/dialog.ts A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-webjar/src/main/node/src/fieldPicker.ts A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-webjar/src/main/node/src/index.ts A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-webjar/src/main/node/src/xwiki.d.ts A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-webjar/src/main/node/tsconfig.app.json A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-webjar/src/main/node/tsconfig.json A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-webjar/src/main/node/tsconfig.node.json A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-webjar/src/main/node/tsconfig.vitest.json A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-webjar/src/main/node/vite.config.ts A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-webjar/src/main/node/vitest.config.ts Log Message: ----------- XWIKI-24831: Add the Records macro with its Live Data mapping Grows the Records macro prototype into a first shippable increment: the macro now renders a real table instead of echoing its parameters, its columns are picked rather than typed, and both halves are tested. * Live Data mapping. The macro owns no rendering: it maps its parameters onto a Live Data backed by the liveTable source and hands them to LiveDataRenderer, the component the liveData macro itself uses. Only class needs work, becoming a className source parameter; the rest are passed through, so a value means the same thing here as it would in a liveData macro. The doc.* headers are translated through a translationPrefix the macro sets itself, as the documents macro does. * The default column list is resolved by the macro. The liveTable source needs an explicit list: given none it renders a table with no columns at all, not one with every column, so an author who omitted the parameter got an empty table. The macro therefore asks the source for the data type's property descriptors, through LiveDataSourceManager so that the PER_LOOKUP source gets its className, and uses the data type's own fields in declaration order. The entry metadata and the Live Data pseudo-columns are left out: the default describes the data type, and an author can add any doc.* column themselves. This is what the documents macro does too, for the same reason. * No advanced configuration is passed, deliberately. LiveDataRenderer marks the content trusted only when the advanced configuration is blank or the author holds script right, so using it would downgrade every table authored without that right and get the link displayers sanitized away. * A TypeScript webjar holds the JavaScript. The columns parameter is a suggester whose candidates come from the Live Data properties REST resource for the data type currently selected. No declarative way to depend on a sibling parameter exists, but a suggester's data source is a callback invoked per keystroke rather than a URL fixed when the displayer template was rendered, so it can read the class input at query time. The coupling is to the input named after the parameter, which is the contract the macro editor itself relies on to assemble a macro call, and nothing else in the editor's DOM is touched. * The bundle is loaded as a classic script and exports nothing. The macro editor builds each parameter field detached and only then appends it to the dialog; jQuery evaluates the field's scripts at that append, and it refuses to fetch a type="module" script by src while evaluating every other one as a classic script. A module script is therefore silently skipped, and a bundle carrying an ES export fails to parse, so the entry point stays free of imports and exports and registers itself with define() for RequireJS instead. * The tabs are hidden until a data type is picked. Every tab is derived from it, so there is nothing to offer before it is set, and the macro editor has no disabled state for a group: the choice is between a tab that is reachable with nothing in it and no tab at all. * Changing the data type warns before discarding the parameters derived from it, then resets the columns, the filters and the sort to their defaults. A column, filter or sort naming a field the new data type does not have would render a table the author cannot explain, and the suggest widget caches its candidates, so the stale ones are dropped too. Declining the warning puts the previous data type back, in the enhanced widget as well as in the element. * The columns element does not carry the xwiki-selectize class. xwiki.selectize.js auto-enhances every element carrying it on xwiki:dom:updated, with default settings and so without the load callback this picker exists for, and $.fn.xwikiSelectize skips an element that is already enhanced. Owning the enhancement means keeping that class off. * Parameter groups follow the dialog the framework can actually build. class is mandatory and ungrouped, so it is rendered as a bare field above the tab strip; it will want a group again once location joins it, but a panel headed Data around a single Data type field earns nothing today. Every optional parameter, in contrast, must carry an explicit group: an ungrouped one is added to the framework's default group, which is pinned at order 0 and which no Java macro can reorder, so it would surface as the first tab ahead of Columns. A mandatory parameter never reaches that branch, which is why class is exempt. * A translation bundle, so the tabs read as names rather than raw group ids. Two parameters the design calls for are left out rather than shipped wrong. location needs an exact prefix predicate the liveTable source cannot express, so it waits on the results page this module will ship. editable maps onto the per-property flag of the Live Data configuration, which is the advanced configuration ruled out above. Tests: 16 Java tests covering the mapping (100% instruction coverage), 37 TypeScript tests covering the picker and the dialog behaviours. The picker's tests are written against the shape the properties resource really answers with, which is an envelope carrying the descriptors under properties rather than a bare array, and against the pseudo-columns it reports next to the real fields. Commit: f879c53ee83cb7737acd43f7b26d0289c2f94b98 https://github.com/xwiki/xwiki-platform/commit/f879c53ee83cb7737acd43f7b26d0... Author: Manuel Leduc <[email protected]> Date: 2026-09-09 (Wed, 09 Sep 2026) Changed paths: M xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-macro/src/main/java/org/xwiki/records/internal/macro/RecordsMacro.java M xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-macro/src/main/java/org/xwiki/records/macro/RecordsMacroParameters.java M xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-macro/src/main/resources/ApplicationResources.properties M xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-macro/src/test/java/org/xwiki/records/internal/macro/RecordsMacroTest.java Log Message: ----------- XWIKI-24831: Open the default column list with the entry title A Records table left with no explicit columns showed the data type's fields and nothing else, so a reader had no way to tell one entry from another and no way to reach the page an entry lives in. The title column is what makes the rest of the row mean something, and it is the first column of every mockup in the design. The default is now doc.title followed by the data type's fields, in declaration order. Naming any column still replaces the list entirely, so an author who wants the fields alone can say so. The rest of the entry metadata stays out: the title is the only piece of it the default needs, and the author can add any doc.* column. A data type with no field of its own now yields a one-column table a reader can still use, rather than no columns at all. Commit: 05f26a703e0c52fd10d447684c60f9554748ac65 https://github.com/xwiki/xwiki-platform/commit/05f26a703e0c52fd10d447684c60f... Author: Manuel Leduc <[email protected]> Date: 2026-09-09 (Wed, 09 Sep 2026) Changed paths: M xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-macro/src/main/java/org/xwiki/records/macro/RecordsMacroParameters.java M xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-macro/src/main/resources/ApplicationResources.properties Log Message: ----------- XWIKI-24831: Say what the description parameter actually does The parameter said the description was "announced to assistive technology", which reads as though it were screen-reader only. It is not: Live Data renders it as a plain visible paragraph above the table (LivedataLayout.vue), in normal flow, and additionally points the layout at it with aria-describedby. An author choosing whether to fill the field needs to know it will be on the page. Note also that it is the table's accessible *description*, not its name, which is a different ARIA concept and is what the design page claimed. Commit: 02d0617539e84448bba29ef229d609cc26f040f3 https://github.com/xwiki/xwiki-platform/commit/02d0617539e84448bba29ef229d60... Author: Manuel Leduc <[email protected]> Date: 2026-09-09 (Wed, 09 Sep 2026) Changed paths: M xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-macro/src/main/java/org/xwiki/records/internal/macro/RecordsMacro.java M xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-macro/src/test/java/org/xwiki/records/internal/macro/RecordsMacroTest.java Log Message: ----------- XWIKI-24831: Always give the table a unique identifier Live Data builds the element id of a table's description as <id>-description and points at it with aria-describedby, so a table without an id got the literal id "undefined-description". Harmless alone, but two such tables on one page shared that element id and the second was described by the first one's text. The macro now always hands Live Data an id, taken from the document's IdGenerator rather than a counter of its own, so a Records table takes its place among the ids the rest of the page generates -- headings included -- and cannot collide with them: * No id from the author yields "records", then "records-1", "records-2" for each further table on the page. * An authored id is kept as it is when it is unique, and suffixed the same way when another table already uses it. Two details of IdGenerator worth knowing. adaptId takes the first character of an id as its prefix and rejects one that is not a letter, so an id the author starts with a digit is prefixed instead of refused. And a macro executed outside a document has no XDOM and so no generator, which still has to yield an id. This makes the id parameter more than a way of keeping each table's reader state apart, which is all its description claims; that wording should follow. Commit: f94f6b54a8be0c40490ced0435eba010f105f82e https://github.com/xwiki/xwiki-platform/commit/f94f6b54a8be0c40490ced0435eba... Author: Manuel Leduc <[email protected]> Date: 2026-09-09 (Wed, 09 Sep 2026) Changed paths: M xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-macro/src/main/java/org/xwiki/records/internal/macro/RecordsMacro.java A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-macro/src/main/java/org/xwiki/records/macro/RecordsLayouts.java M xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-macro/src/main/java/org/xwiki/records/macro/RecordsMacroParameters.java M xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-macro/src/main/resources/ApplicationResources.properties A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-macro/src/main/resources/templates/html_displayer/recordslayouts/edit.vm M xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-macro/src/test/java/org/xwiki/records/internal/macro/RecordsMacroTest.java Log Message: ----------- XWIKI-24831: Close the layout choice and drop the entries per page * The layout is now picked from two radio buttons, table and cards, rather than typed as a comma-separated list of layout identifiers. The dialog is in a position to name the layouts a table of records can reasonably use, and an author who needs anything else has the liveData macro. The widget needs no JavaScript of its own: the macro editor already keeps a radio group together and checks the one matching the parameter value. * The entries per page parameter is gone. Nothing is lost by leaving it out: an unset limit is Live Data's own default of fifteen, and the reader can change the page size from the pagination controls anyway, so the parameter only chose a starting point. Commit: f2df3c0a74fcaefce95b9dfd19ec767b791867bc https://github.com/xwiki/xwiki-platform/commit/f2df3c0a74fcaefce95b9dfd19ec7... Author: Manuel Leduc <[email protected]> Date: 2026-09-09 (Wed, 09 Sep 2026) Changed paths: M xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-webjar/src/main/node/src/index.ts Log Message: ----------- XWIKI-24831: Hide the columns placeholder once columns are picked The columns field is a multiple-value suggest widget, and the suggest widget is backed by Tom Select, whose hidePlaceholder setting defaults to `mode !== 'multi'`. So the placeholder stayed next to the selected items. Here it names the default column list, which means it was telling the author the table shows the title and every field while they were looking at the columns they had just picked. Commit: 41aaeb4cb6d359d4e242c0c9fa6b74e4972b05b6 https://github.com/xwiki/xwiki-platform/commit/41aaeb4cb6d359d4e242c0c9fa6b7... Author: Manuel Leduc <[email protected]> Date: 2026-09-09 (Wed, 09 Sep 2026) Changed paths: M xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-macro/src/main/java/org/xwiki/records/macro/RecordsMacroParameters.java A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-macro/src/main/java/org/xwiki/records/macro/RecordsSort.java M xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-macro/src/main/resources/ApplicationResources.properties A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-macro/src/main/resources/templates/html_displayer/recordssort/edit.vm A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-webjar/src/main/node/src/__tests__/sortPicker.test.ts M xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-webjar/src/main/node/src/fieldPicker.ts M xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-webjar/src/main/node/src/index.ts A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-webjar/src/main/node/src/sortPicker.ts Log Message: ----------- XWIKI-24831: Pick the sort criteria instead of typing them The sort parameter now uses a suggester offering each field of the data type twice, once ascending and once descending, so a criterion is one choice and the direction is never typed. The platform has a generic sort widget, uicomponents/widgets/sortPicker.js, and it is deliberately not used: it edits a single criterion through a field select and an order select, while this parameter holds an ordered list of criteria. The suggester's drag-and-drop plugin is what lets that order be authored. That widget would also need its field select filled from the sibling class parameter, which is the same client-side work as this picker, so it would buy the harder half and still lose the list. A stored criterion is resolved exactly rather than searched, because the suggester refuses free text: a criterion naming no direction, or naming a field the data type no longer has, would otherwise be dropped the next time the dialog opens. The lookup of the selected data type is now shared between the pickers rather than repeated. Commit: 7da98141c2c277250672f82b97000ffd75fc6641 https://github.com/xwiki/xwiki-platform/commit/7da98141c2c277250672f82b97000... Author: Manuel Leduc <[email protected]> Date: 2026-09-09 (Wed, 09 Sep 2026) Changed paths: A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-macro/src/main/java/org/xwiki/records/macro/RecordsFilters.java M xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-macro/src/main/java/org/xwiki/records/macro/RecordsMacroParameters.java M xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-macro/src/main/resources/ApplicationResources.properties A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-macro/src/main/resources/templates/html_displayer/recordsfilters/edit.vm A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-webjar/src/main/node/src/__tests__/filterPicker.test.ts M xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-webjar/src/main/node/src/fieldPicker.ts A xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-webjar/src/main/node/src/filterPicker.ts M xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-webjar/src/main/node/src/index.ts Log Message: ----------- XWIKI-24831: Suggest the fields and the values of a filter The filters parameter now uses a suggester holding one item per field=value constraint, which is what the renderer parses the query string into. The suggestions come in two steps, since only the author knows which field they mean: the fields until a = is typed, then that field's values. Picking a field puts "field=" back in the text box rather than leaving half a constraint behind as an item. The values are not invented here. The Live Data properties resource already reports a filter.searchURL for every property whose values are enumerable, with an {encodedQuery} placeholder, and it is the same URL the Live Data filter row queries, so the dialog offers what a reader would be offered in the rendered table. A property without one is filtered by typing, which is why this is the only picker of this dialog that accepts free text. A suggested value is percent-encoded, because the renderer URL-decodes each half of a constraint: a value holding & or = would otherwise be read as another constraint. Repeating a field is left possible, since the renderer turns that into two constraints on that field, and it works because an item's value is the whole pair. Commit: 048056ff5c95e90a27103bc73fb3a6350f75fd54 https://github.com/xwiki/xwiki-platform/commit/048056ff5c95e90a27103bc73fb3a... Author: Manuel Leduc <[email protected]> Date: 2026-09-09 (Wed, 09 Sep 2026) Changed paths: M xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-webjar/src/main/node/src/__tests__/sortPicker.test.ts M xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-webjar/src/main/node/src/index.ts M xwiki-platform-core/xwiki-platform-records/xwiki-platform-records-webjar/src/main/node/src/sortPicker.ts Log Message: ----------- XWIKI-24831: Stop offering a field that is already sorted on Both directions of a field disappear from the sort suggestions once that field is used, rather than only the criterion picked. Sorting a field twice says nothing the first criterion did not already say, and offering the pair invites reading it as a choice between directions when it is not one. The widget caches what it has loaded per query and keeps the options it has already seen, so neither the filtering at load time nor a removal would show through on its own. Adding or removing a criterion therefore drops the options that are not backing a selected one, which also clears that cache, and the next dropdown loads the rest afresh. Compare: https://github.com/xwiki/xwiki-platform/compare/f8d4ad649750%5E...048056ff5c... To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-platform/settings/notifications