This is the release notes for XWiki Commons, XWiki Rendering, XWiki Platform and XWiki Enterprise. They share the same release notes as they are released together and have the same version.

This release comes with a simplified Wiki Creation Wizard and the ability to organize and filter extensions by category in the Extension Repository. The install date and the user that performed the install are now available in the extension details, and the extensions that were installed explicitly are now displayed distinctly. A stronger confirmation should prevent users from deleting wikis by mistake from now on. The developers may be interested by the API improvements made to the Mail Sender and Extension Manager modules.

New and Noteworthy (since XWiki 7.0 Milestone 1)

Full list of issues fixed and Dashboard for 7.0.

Wiki Creation

During the wiki creation, Distribution Wizard is not triggered anymore. Instead, the whole wiki creation process has been moved into a job, and everything happens inside the Wiki Creation Wizard (with a progress bar and a logging area):

The Wiki Provisioning Step has been integrated into the job too.

When a wiki is created from a template, we now have a message in the logs that displays which document is copied.

Extension categories

It's now possible to indicate a predefined category for each extension in the repository:

It's also possible to filter and order extension by category:

Extension Manager Improvements

You can now distinguish between the extensions that have been installed directly (by you or a different user) and the extensions that have been installed as transitive dependencies, when looking at the list of installed extensions.

Also, the details of an installed extension now include the install date and the user that installed that extension. This information will be available only for extensions that are installed or upgraded from now on (directly or indirectly). Extensions that are already installed have this information only if they were installed directly (not as dependency).

Miscellaneous

The user/group displayer is now showing the wiki for local users/groups in edit mode too (the wiki was shown only in view mode previously).

When deleting a wiki the confirmation page now asks to type in the wiki identifier to prevent accidental deletion.

The Main.RssFeeds documentation page has been removed since it wasn't linked from anywhere, provided little value in itself and wasn't dynamic (the RSS features for each extensions depends on the extension being installed and if the extension is not installed or uninstalled the RssFeeds page gets broken links).

See the full list of JIRA issues fixed in this release.

For Developers

Mail Sender API Improvements

The Mail Sender API has been improved to allow sending mails to a list of users, a list of groups and a list of email addresses, all at once. It also supports excluding users, groups and email addresses. Last, it ensures that recipients don't get duplicate mails. Before 6.4.2/7.0M2, you could send a mail either to a list of users or to a group (and to an email address) but you had to use several API calls for that and you had to handle yourself potential mail duplication (if a user was inside your user list and inside the group you were sending to for example).

Using the new API, the following example will send a template email to all the users in the XWiki.MyGroup group, to the XWiki.User1 and XWiki.User2 users + to the [email protected] email address.

Also note that contrary to the previous API to send email to a group, the new API handles nested groups (i.e. if the XWiki.MyGroup group contains other groups, all users of those other groups will also receive the template email)!



## Parameters for the 'template' MimeMessageFactory

#set ($templateParameters = {'language' : $xcontext.language, 'velocityVariables' : { 'var1' : 'value1' }})



#set ($templateReference = $services.model.createDocumentReference('', 'Space', 'MailTemplatePage'))

#set ($parameters = {'hint' : 'template', 'parameters' : $templateParameters, 'source' : $templateReference})



#set ($groupReference = $services.model.createDocumentReference('', 'XWiki', 'MyGroup'))

#set ($user1Reference = $services.model.createDocumentReference('', 'XWiki', 'User1'))

#set ($user2Reference = $services.model.createDocumentReference('', 'XWiki', 'User2'))



#set ($source = {'groups' : [$groupReference], 'users' : [$user1Reference, $user2Reference], 'emails' : ['



#set ($messages = $services.mailsender.createMessages('usersandgroups', $source, $parameters))

#set ($mailResult = $services.mailsender.send($messages, 'database'))

{{/velocity}} {{velocity}}## Parameters for the 'template' MimeMessageFactory#set ($templateParameters = {'language' : $xcontext.language, 'velocityVariables' : { 'var1' : 'value1' }})#set ($templateReference = $services.model.createDocumentReference('', 'Space', 'MailTemplatePage'))#set ($parameters = {'hint' : 'template', 'parameters' : $templateParameters, 'source' : $templateReference})#set ($groupReference = $services.model.createDocumentReference('', 'XWiki', 'MyGroup'))#set ($user1Reference = $services.model.createDocumentReference('', 'XWiki', 'User1'))#set ($user2Reference = $services.model.createDocumentReference('', 'XWiki', 'User2'))#set ($source = {'groups' : [$groupReference], 'users' : [$user1Reference, $user2Reference], 'emails' : [' [email protected] ']})#set ($messages = $services.mailsender.createMessages('usersandgroups', $source, $parameters))#set ($mailResult = $services.mailsender.send($messages, 'database')){{/velocity}}

Group Member Iterator

A new ReferenceUserIterator iterator has been introduced to iterate over all the users found in a list of users/groups. It supports the following:

Ability to iterate over a list of references (either group or user) or a single user/group

Handles nested groups

Ability to return user data (e.g. user's email) and to programatically skip some entries based on programmatic condition

Ability to exclude users/groups

Notes:

Right now duplication is not handled at the level of UserIterator (thus for example if a user is a member of several groups it'll be returned several times).

(thus for example if a user is a member of several groups it'll be returned several times). This code is not performant as it will load one document per group and per user found. There's currently no way of handling this in a performant way

Example 1: List all users of a group by returning references

{{ groovy }}

import com.xpn.xwiki.internal.plugin.rightsmanager.*

import org.xwiki.model.reference.*

import org.xwiki.context.*



def groupReference = new DocumentReference ( "xwiki" , "XWiki" , "XWikiAllGroup" )

def resolver = services . component . getInstance ( DocumentReferenceResolver . TYPE_STRING , "explicit" )

def execution = services . component . getInstance ( Execution . class )

def iterator = new ReferenceUserIterator ( groupReference , resolver , execution )

iterator . each () {

println "* ${it}"

}

{{/ groovy }}

Example 2: Get all emails from all users inside the passed groups

{{ groovy }}

import com.xpn.xwiki.doc.*

import com.xpn.xwiki.objects.*

import com.xpn.xwiki.internal.plugin.rightsmanager.*

import org.xwiki.model.reference.*

import org.xwiki.context.*



def group1Reference = new DocumentReference ( "xwiki" , "XWiki" , "XWikiAllGroup" )

def group2Reference = new DocumentReference ( "xwiki" , "XWiki" , "XWikiAdminGroup" )

def resolver = services . component . getInstance ( DocumentReferenceResolver . TYPE_STRING , "explicit" )

def execution = services . component . getInstance ( Execution . class )



class EmailUserDataExtractor implements UserDataExtractor < String >

{

public String extractFromSuperadmin ( DocumentReference reference )

{

return null

}



public String extractFromGuest ( DocumentReference reference )

{

return null

}



public String extract ( DocumentReference reference , XWikiDocument document , BaseObject userObject )

{

return userObject . getStringValue ( "email" )

}

}



def iterator = new UserIterator ([ group1Reference , group2Reference ], [], new EmailUserDataExtractor (), resolver , execution )

iterator . each () {

println "* ${it}"

}

{{/ groovy }}

Extensions improvement and new features

Extension category

Each extension can now expose a category (flavor, application, macro...).

Advanced extensions search

A new org.xwiki.extension.repository.search.AdvancedSearchable extending org.xwiki.extension.repository.search.Searchable provide field based filtering and ordering to extensions search. It's implemented by default core, local, installed, xar extensions repositories.

Advanced extensions search in REST protocol

Support for advanced filtering and ordering or extensions search result has been added XWiki Repository protocol and client. See Repository Module.

Custom properties in REST protocol

Support for missing custom properties has been added to the XWiki Repository REST protocol. See Repository Module. Only String properties are supported for now.

Miscellaneous

$datetool has a new method to access the DateFormatSymbols {{velocity}}

#set ($currentLocale = $services.localization.currentLocale)

#set ($dateFormatSymbols = $datetool.getDateFormatSymbols($currentLocale))

$jsontool.serialize($dateFormatSymbols.shortMonths)



## Output for French locale:

## ["janv.","févr.","mars","avr.","mai","juin","juil.","août","sept.","oct.","nov.","déc.",""]

{{/velocity}}

has a new method to access the Message Stream script service now offers a getLastError() method to get the last error.

method to get the last error. "input" displayed Static and Database Lists separators handling has been improved to properly allow using multiple separators at once for entering data (including escaped separators inside list values). More importantly, when displaying an existing list inside an input, the existing values will always be separated using the first separator specified in the object's class for the edited object property. For non-relationally stored properties, the value that is stored in the database as a LargeStringProperty will always be separated using the default pipe ("|") separator. See XWIKI-10098

The /deleteversions/ action now supports the "latest" and "previous" pseudoversions and the /rollback/ action now supports the "previous" pseudoversion. See XWIKI-11841

Upgrades

The following dependencies have been upgraded:

Translations

The following translations have been updated:

German

French

Latvian

Romanian

Tested Browsers & Databases

Here is the list of browsers we support and how they have been tested for this release:

Browser Test Result Google Chrome 40 Not Tested Mozilla Firefox 33 Jira Tickets Marked as Fixed in the Release Notes Internet Explorer 8 Not Tested Internet Explorer 9 Not Tested

Here is the list of databases we support and how they have been tested for this release:

Database Test Result HyperSQL 2.3.2 Not Tested MySQL 5.6.17 Jira Tickets Marked as Fixed in the Release Notes Oracle 11.2 Not Tested PostgreSQL 9.4.0 Not Tested

For the full list of tests see this page.

Known issues

Backward Compatibility and Migration Notes

General Notes

When upgrading make sure you compare your xwiki.cfg, xwiki.properties and web.xml files with the newest version since some configuration parameters may have been modified or added. Note that you should add xwiki.store.migration=1 so that XWiki will attempt to automatically migrate your current database to the new schema. Make sure you backup your Database before doing anything.

Issues specific to XWiki 7.0M2

The Watchlist class and its objects have been migrated to use relationally stored DBList properties instead of TextArea properties in order to solve scalability issues that occurred when too many elements were being watched by a user. See XWIKI-7339

The upgrade to DBCP 2.1 has caused to require a JDBC 4 driver and some Hibernate configuration properties have been removed and new ones created. The following properties have been removed: dbcp.maxActive replaced by dbcp.maxTotal dbcp.maxWait replaced by dbcp.maxWaitMillis Note that we've kept backward compatibility support for the old properties so that you don't need to immediately modify your hibernate.cfg file (although we recommend you do that!). Also note that even though the following properties were defined in hibernate.cfg they were not handled by XWiki's code (nor by DBCP 1.3 - which was the version we were using prior to moving to 2.1). Since they had no effect they've now been removed: dbcp.whenExhaustedAction . Note that the default action is BLOCK in Commons Pool (used by DBCP) dbcp.ps.whenExhaustedAction dbcp.ps.maxWait dbcp.ps.maxIdle

and some Hibernate configuration properties have been removed and new ones created. The following properties have been removed:

API Breakages

The following APIs were modified since XWiki 6.4.2:

Add support for categories to extension. It should not be an issue for most Extension implementations which are supposed to extend AbstractExtension

org.xwiki.extension.Extension: Method 'public java.lang.String getCategory()' has been added to an interface

Added a method to get the date when an extension was installed.

org.xwiki.extension.InstalledExtension: Method 'public java.util.Date getInstallDate(java.lang.String)' has been added to an interface

Added support for associating custom install properties (e.g. the user that triggers the install) to the namespace where the extension is installed.

org.xwiki.extension.InstalledExtension: Method 'public java.lang.Object getNamespaceProperty(java.lang.String, java.lang.String)' has been added to an interface

org.xwiki.extension.repository.InstalledExtensionRepository: Method 'public org.xwiki.extension.InstalledExtension installExtension(org.xwiki.extension.LocalExtension, java.lang.String, boolean, java.util.Map)' has been added to an interface

Added support for advanced installed extensions search.

org.xwiki.extension.repository.InstalledExtensionRepository: Method 'public org.xwiki.extension.repository.result.IterableResult searchInstalledExtensions(java.lang.String, org.xwiki.extension.repository.search.ExtensionQuery)' has been added to an interface

Using String instead of JRCS Version for better flexibility. Probably should not have been public from the start.