Changes Report

Support for Live Data description

The Live Data macro has a description parameter, allowing to define a textual description of the content of the Live Data.

Example:

{{liveData
  id="users"
  properties="_avatar,doc.name,first_name,last_name"
  source="liveTable"
  sourceParameters="className=XWiki.XWikiUsers&translationPrefix=xe.userdirectory."
  description="The list of all users:"
/}}

Support for Live Data in Velocity

It is now possible to insert a Live Data using scripting instead of using the usual liveData macro.

Example using Velocity:

$services.liveData.render({
  'id': 'users',
  'properties': '_avatar,doc.name,first_name,last_name',
  'source': 'liveTable',
  'sourceParameters': 'className=XWiki.XWikiUsers&translationPrefix=xe.userdirectory.'
})

Addition of "panel-header-color"

Added a new parameter to the color theme, to control panel header text color. See the Flamingo Color Theme documentation.

More details

Updated drag and drop feature of the Live Data Macro

The appearance of drag and drop controls for Live Data columns has been updated to be more straightforward to use. In addition, keyboard control is now fully supported for those controls. See Live Data documentation for more details on these new controls.

Improve the registration & Log-in experience

Multiple steps of the registration process have been updated and improved in accordance with design research done earlier:

• The registration and authentification buttons for guest users have been moved from the drawer to the navigation bar for increased visibility
• The registration form validation has been improved to provide a precise status on every field before trying to submit it.
• The successful registration landing page is now looking a bit more welcoming.

Customize safe/unsafe database queries

This version introduces a new configuration to force the HQL query validation to consider safe or unsafe a set of queries (which can be express as regular expressions). See Query Module for mode details.

Realtime Editing of Rendering Macros

The realtime WYSIWYG editor has changed the way it handles rendering macros. Previously, the macro output was propagated from the user that inserted or last modified the macro parameters to the other participants in the realtime session. This was working fine for static macros, that don't rely on custom CSS and JavaScript, but it was creating problems for dynamic macros (e.g. live data). Starting with this version, the macro output is not synchronized anymore between the users. When a user inserts a macro or modifies the parameters of an existing macro call, the other users will get their content re-rendered server side in order to get the updated macro output (which often depends on the current user, e.g. on their access rights). See the realtime WYSIWYG editor documentation for more information.

Live Data async actions

It is now possible to allow a Live Data actions to be asynchronous. Instead of following the link, the action will be performed in the background, and the Live Data refreshed at the end of the process.
Additionally, it is possible to define a user confirmation before performing the action.

Example:

{{liveData
  id="test"
  properties="name,_actions"
  source="liveTable"  sourceParameters="className=Space.MyClass"
}}{
  "meta": {
    "actions": [{
        "id": "delete",
        "async": {
          "httpMethod": "POST",
          "loadingMessage": "Loading",
          "successMessage": "Delete Success",
          "failureMessage": "Failed",
          "body": "newBacklinkTarget=&updateLinks=false&autoRedirect=false&form_token=${services.csrf.token}&confirm=1&async=true",
          "headers": {
            "Content-Type": "application/x-www-form-urlencoded"
          }
        }
      }]
  }
}
{{/liveData}}

Versioning Store API improvements

The Versioning Store interface now exposes two new methods designed to directly fetch subsets of revisions:

Collection<Version> getXWikiDocVersions(XWikiDocument doc, RevisionCriteria criteria, XWikiContext context) throws XWikiException
long getXWikiDocVersionsCount(XWikiDocument doc, RevisionCriteria criteria, XWikiContext context) throws XWikiException

If you maintain a custom implementation of a Versioning Store, there should be no breaking change since these methods have default implementations. However, you are still encouraged to implement them to improve performances.

Consequently, the Document API now offers a method to directly obtain the number of existing revisions, fetching the information directly from the Versioning Store without actually loading the revisions:

#set ($criteria = $xwiki.criteriaService.revisionCriteriaFactory.createRevisionCriteria($author, $period, $includeMinorVersions))
#set ($revisionsCount = $doc.getRevisionsCount($criteria))

Operations that required to load the complete history of a document before filtering the revisions (e.g., displaying a paginated document history) have been modified to benefit from these changes, they should now be faster and use less memory.

Script Safe Provider

The old ScriptSafeProvider tool has been move to a public package. It's making much easier to make a script API safe by wrapping what it returns to make sure:

• it really only can use the method exposed in the returned API
• there is some protection added to the methods called in the returned objects
• it's easy to make collection of those objects safe

See Script Module for more details.

Updated link underlining preference

The extra accessibility preference is removed, in favor of a more precise Link underlining preference. The link underlining can be set to three values:

• Yes: all links are underlined
• Only inline links: Only links in text blocks are underlined. This is the new default value. This is a compromise that allows to easily spot links in blocks of text without highlighting them in places where they are easy to see.
• No: No links are underlined. This is equivalent to the previous default value.

Note that on hover, links are always underlined, independently of the underline setting.

The screenshots display a page with the different preferences selected, in the same order as the one described above.

Notifications custom filters livedata can be filtered and sorted

The notifications settings have been improved to allow filtering and sorting the custom filters livedata: this allows a better handling of the watching pages filters.

Upload summary

When upload summaries are enabled by the administrator, descriptions can be added to attachment uploads and will be displayed on the revision history of the attachment.

Attachment storage size reduced

The current version of each attachment used to be duplicated in the storage, it's not the case anymore. See Filesystem. Note that it only applies to new attachments, existing attachments are not migrated during upgrades.

Revamping of notification watch buttons

We changed the way one can decide to watch a location in XWiki.

Starting with this release, a button is present in all pages next to the edit button. This buttons shows by default the current state of the page:

• Followed: if you're following the page to receive notifications about it
• Blocked: if you're blocking the page to not receive notifications about it
• Not set: in case you haven't set any preferences for watching or blocking it
• Custom: this appear if you have some preferences corresponding to that page but that are specific to some specific event types, or some specific formats (e.g. you only want to receive some notifications by email for a specific location).

If you click on the button, you will obtain a modal window explaining the current state (e.g. you might have a page followed because you are actually following a space containing that page), and allowing you to perform actions to change that state.
That modal also contains a link to access directly the notification filters settings: this is useful if you want to properly review your settings or perform custom actions from there. Note that if the current state is custom you can only perform actions from the notification filters settings. 

Realtime WYSIWYG Source button

When using Realtime WYSIWYG Editing, editing and viewing the source wiki syntax is now possible by clicking the Source button in the toolbar.

When editing the source wiki syntax, the realtime editing session is interrupted temporarily. Once the user is done editing the source wiki syntax, the editor re-joins the realtime editing session automatically if it is safe to do so.
If the user wants to re-join the realtime editing session anyway, they can click the "Allow Realtime" Checkbox.

Differentiation of message types

Message boxes now include icons in their design. It makes it easier to differentiate one type of message from the other without having to rely on color (especially helpful for colorblind users!). In addition, their design has been slightly reworked to fit better in the current skin.

Presentation import updated

The importing of presentations has been rewritten to work with LibreOffice 24.2 and more recent versions. As part of this work, we increased the default image width to 1920 pixel and increased the image quality to 95. Previously set configuration options still apply and take precedence over these new defaults. Additionally, new options have been added to directly configure presentation import in xwiki.properties, including the ability to change the image format to PNG for even higher image quality. Refer to the documentation for details.

Incoming link updates wait for indexing

When updating links as part of renaming or copying a document or attachment, the operation now waits for link indexing to complete. This waiting can optionally be skipped after ten seconds. For details, see the documentation about link indexing.

Page Tree Sort

The Page Tree (Document Tree) Macro has a new parameter named "Sort by" (sortDocumentBy) that controls how the pages (documents) are sorted. This sort parameter has been exposed also on the Children Macro, which is a wrapper around the Document Tree Macro. For now, you can sort the pages ascending or descending based on 4 fields: name, title, last modification date and creation date. Here's an example:

{{documentTree sortDocumentsBy="date:desc"/}}

{{children sort="creationDate"/}}