Changes Report
Password Security Policy
It is now possible to chose some password policy rules that are applied when passwords are chosen (for registration) or when they are changed (by users or administrators).
The password policy rules are available in the Administration > Users & Rights > Registration.
You might find more details on the User Management.
Rename AWM Application
Starting with this version you can rename/move an application created with App Within Minutes by renaming/moving its home page. Be aware though that the application code is going to be regenerated if you rename the application, which means that code customizations will be overwritten as a consequence.
Checkout the App Within Minutes documentation for more information.
Partial Wiki XAR Export
You can now do a partial export of your wiki from the wiki administration by selecting the pages you wish to export from a tree.
Orphaned Dependencies Cleanup
A new step has been added to the Distribution Wizard right after the Flavor step. Its job is to make sure no orphaned dependency (extension installed as dependency but which don't have any backward dependency left) is left in the installed extensions. The step suggests to uninstall the invalid ones by default and make the others top level extensions (i.e. taken into account by the upgrade job). Among other things, it fixes long standing problems caused by deprecated extensions no longer included in the Standard Flavor, like the Watchlist UI.
Improved view of XClasses in Object editor
It is easier now to find the XWiki Class of interest by using the new suggest box that replaces the old select element. The old way of searching is still available so the user still can explore the full list of available classes.
Exclude top level application pages from the Navigation Panel
The top level application pages are now excluded by default from the Navigation Panel. This allows the Navigation Panel to focus more on your own content pages.
Warning conflict when editing a page
The edition of document is now protected against edition conflicts. It means that a user might now obtain a warning conflict window, in case another user saved the document in the meantime. This window prevents from erasing the changes made by the first user having saved.
Inline editing for wiki macros
When developing a wiki macro, you can now insert the content of that macro by using a dedicated macro:
This new way of inserting the wiki macro content makes it by default editable directly in the WYSIWYG editor. If you want to test it, you can, for example, create the following wiki macro and try it:
{{box}}
{{wikimacrocontent/}}
{{/box}}
The content's size is $xcontext.macro.content.length() characters.
{{/velocity}}
Attachment Picker Widget
A new widget is available to help users select or upload attachments. Here's how you can use it:
{{html clean="false"}}
#set ($attachmentPickerParams = {
'name': 'attachment',
'value': '[email protected]',
'data-upload-allowed': $services.security.authorization.hasAccess('edit'),
'data-accept': 'image/,.mp4,.pdf',
'multiple': 'multiple',
'placeholder': 'Select attachment'
})
#attachmentPicker($attachmentPickerParams)
{{/html}}
{{/velocity}}
Checkout the Suggest Widget documentation for more information.
Merge on save
Continuing the work started on to warn users when performing conflicting edits on the same page, we finally implemented a merge on save mechanism.
This means that in case of conflict edition (two users saving the same document at the same time), instead of always displaying a window to the user asking what to do, we first try to perform a merge of both document. If the changes concerned two very different parts of the document (two different sections, an edit performed on an object against an edit of the content, etc) the user won't notice that a merge has been performed.
Now, some conflicts might still occur if both users tried to edit the same part of the document. In that case, a new window is displayed asking the user what to do.
The user will now have three different choices:
- Merge the document and fix conflict with his/her own changes: this means that as much as possible, we try to merge the changes. Only for the part that are conflicting, we only kept the changes from the last user. This is the recommended choice.
- Force save the document: this means no merge at all will be performed. Only the changes performed by the last user will be saved. It basically discards the changes made by the previous user.
- Reload the editor: this choice might be taken very carefully as it might cause a loss of data. It means that the current changes performed on the document will be completely lost and the editor will be reloaded with the last changes.
The conflict window now display the changes that will be performed for each choices. Be careful with the parts in red since it shows what part of the document will be lost during the operation. Note that it's also possible to select two specific versions of the document to perform a comparison before making a choice.
Page Picker for Macro Parameters
Macro parameters that expect a page reference can now use the Page Picker to help the users select the page without having to know the reference syntax. You can see this in action when inserting the Include, Display, Table of Contents, Dashboard and Context macros from the WYSIWYG editor.
Attachment Picker for Macro Parameters
Macro parameters that expect an attachment reference can now use the Attachment Picker to help the users select or upload a file without having to know the reference syntax. You can see this in action when inserting the Office Macro from the WYSIWYG editor.
Visual Diff
You can now view how a page has changed visually from one version to another. The changes are computed on the rendered page content. You can click on the ellipsis to expand the context (to see the parts that have not changed). See the documentation for more information.
Multiple login attacks protection
A new Authentication Security Module has been integrated to prevent attacks on user accounts. This module allows to perform different strategies in case of repeated authentication failures.
For now two strategies are provided:
- to ask user to answer a CAPTCHA challenge (default strategy)
- to disable user account (in which case an administrator would have to activate it back)
The strategy is triggered whenever a user repeatedly failed to login in a given time window. The number of failed attempts and the duration of the time window are configurable in Administration > Authentication. Default values are 3 failed attempts in 5 minutes would trigger a CAPTCHA challenge for users.
Enable/Disable user account
it is now possible to disable a user account and to enable it back from his/her profile. A disabled user is able to login but cannot perform any action once logged-in.
Color Picker
The color picker used by the Flamingo Theme Application can now be re-used thanks to a new Velocity macro:
'name': 'color',
'value': '#85d4a9'
})
#colorPicker($colorPickerParams)
Checkout the Color Picker documentation for more information.
Improved Date Picker
The Date picker used to edit date properties has been improved. The new version is better integrated with the Bootstrap-based Flamingo skin and its UI adapts better to the provided date format configuration (e.g. by hiding UI elements that don't make sense). Checkout the Date Time Picker documentation for more information.
Date Time Picker
A new Velocity macro is available to create a date & time picker:
'name': 'date',
'data-format': 'dd/MM/yyyy HH:mm:ss'
})
#dateTimePicker($dateTimePickerParams)
Checkout the Date Time Picker documentation for more information.
Custom conflict resolution in Extension Manager
We improved the Extension Manager conflict resolution to allow making specific choices for fixing some conflicts.
The conflicts that can be fixed with custom choices are displayed directly in the changes display by an orange bar. A blue area is reserved for the conflict resolution.
This blue area displays some text, and a select with several choices. The displayed text in the blue area is what will be used for fixing the conflict, you can see the text changing for each choice.
The conflict choices are the following:
- current version (default): the conflict is fixed by getting the current changes
- before your changes: the conflict is fixed by getting what was there before you starting to edit. Both latest version saved and your current changes would be lost for this conflict,
- latest version saved: the change made on the latest version saved (the one you are conflicting with) are taken to fix the conflict
- custom version: with this option, a text area is displayed to allow you to enter any new value to fix the conflict. Multiple lines can be entered.
If the choice text displays something in red, it is because no content is actually available for the chosen version to fix the conflict: usually it means the content in conflict will be removed with the choice made.
Asynchronous rendering improvements
- Asynchronous support has been added to page content execution (include macro, display macro, view, #getRenderedContent, etc.)
- Asynchronous support has been added to templates, see Template Module
- Calls to hasAccess and checkAccess are automatically associated to cached elements and invalidated if the right change
- Force refresh in the browser now also apply to asynchronous rendering cache located on server side
- Support has been added for the following context elements (see Async)
- RenderingContext target syntax
- RenderingContext default syntax
- RenderingContext restricted
- UI improvements
- The spinner is displayed only after 500ms so that it does not get in the way when the asynchronous execution is very fast
- The AJAX request now retry every 500ms instead of blocking a HTTP input thread forever
Independent Conflict Resolution
We introduced few releases ago a mechanism to detect and handle conflict edition (i.e. when two users save changes on the same page) during page edition.
Starting with this release, the conflict edition window allows one more choice: to fix each conflict individually.
This new choice is marked as advanced since it's not something easy to handle.
When choosing the new option, the UI is updated to display the changes between the latest version saved and the current version the user is trying to save. At each place a conflict occurred, the changes display an orange bar and a blue area is reserved for the conflict resolution.
This blue area displays some text, and a select with several choices. The displayed text in the blue area is what will be used for fixing the conflict, you can see the text changing for each choice.
The conflict choices are the following:
- current version (default): the conflict is fixed by getting the current changes
- before your changes: the conflict is fixed by getting what was there before you starting to edit. Both latest version saved and your current changes would be lost for this conflict,
- latest version saved: the change made on the latest version saved (the one you are conflicting with) are taken to fix the conflict
- custom version: with this option, a text area is displayed to allow you to enter any new value to fix the conflict. Multiple lines can be entered.
If the choice text displays something in red, it is because no content is actually available for the chosen version to fix the conflict: usually it means the content in conflict will be removed with the choice made.
Replace Author when Deleting Users
Starting with this version deleting a user from the Administration requires 2 steps:
- You have to disable the user first. Disabling the user prevents them from logging in and it doesn't break the scripts that they last modified. This is the recommended way to "remove" an user account from your organization.
- If you really need to completely remove the user account then you can delete it. However, you should choose another user account with similar access rights to replace the delete one as page author of existing pages, otherwise, any scripts inside those existing pages will lose their rights and stop working.
