Missing notification properties in user objects after upgrade


Hi all.

Upgraded from 9.1.2 to 9.5.1 (using deb/mysql and aptitude update, xwiki.store.migration=1) and found that new notification functionality doesn’t work: when I try to change notification properties server returns 500, with exceptions in log like this:

Jul 24, 2017 4:46:56 PM org.restlet.engine.application.StatusFilter doHandle
WARNING: Exception or error caught in status service
java.lang.IllegalStateException: The Web form cannot be parsed as no fresh content is available. If this entity has been already read once, caching of the entity is required
at org.restlet.engine.util.FormUtils.parse(FormUtils.java:272)

After some research I found that user objects don’t have appropriate notification fields. And if I add these properties manually on user page (by adding class XWiki.Notifications.Code.NotificationPreferenceClass to user object) I am able to save/edit these values.

The question: how to upgrade properly to have this functionality working?



Guys, could you provide some glue so I could fix work of this feature?

Which things to check, which configs/pages to edit?


Hi, I’ve pinged the authors of the notifications feature for you. This is holiday time though and I don’t know when they’ll be able to answer. Can’t help much on my side (on holidays too btw ;)). Hold on a bit more!


Hi aremnev !

We have changed several parts of the front end code used in the notification center during the past releases ; the exception you’re describing seems to come from a failed REST call. Therefore, have you tried to clear your browser cache before toggling a notification property ?

If you have already tried that and the problem persists, could you make sure that you have the correct version (9.5.1) of the Notifications API and of the Notifications Application in the Extension Manager ?



I am on 9.5.1 and I too am facing some problems. I can’t save notification settings.
It just says… error. Failed to save your settings.



Updated to 9.6, problem persist.
Both Notification API and Notification Application are 9.6.

Yes, I tried to clear cache and use other browser, this doesn’t help.

I have an nginx in front of Tomcat so I thought this can be a cause (like some request headers are not filtered). But in this case it’s not clear why it started working after I added notification preference field manually? May be this info will help to find out:

Request/response details

Request URL:
Request Method:POST
Status Code:500 Internal Server Error
Remote Address:
Referrer Policy:no-referrer-when-downgrade
Response Headers
Date:Tue, 01 Aug 2017 04:20:12 GMT
Request Headers
Accept-Encoding:gzip, deflate, br
Content-Type:application/x-www-form-urlencoded; charset=UTF-8
Cookie:JSESSIONID=9D316D290C1B81AAD8D8916F649F8E8F; username=“jKTm7CiF/xk_”; password=“BiCUwwtUqTyXMNsAdjiNcQ__”; rememberme=“false”; validation=“5fe445fb3cabe14229e5f772d8f75f70”; _ga=GA1.4.831717514.1500884111; _gid=GA1.4.1909367384.1501560794; _gat=1
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.125 Safari/537.36
Query String Parameters
Form Data

I saw similar problem in mail list but with no solution:


Hi again,

So, I tried to reproduce this bug by installing a 9.2 instance, adding / updating preferences and then upgrading to the last version of XWiki.

Indeed, some changes have been made during the past months on the NotificationPreferenceClass, which is responsible of storing the informations about the user notification configuration.

From my point of view, the problem is that you have XObjects of the NotificationPreferenceClass stored in user profiles that are using the an old schema of the NotificationPreferenceClass. In theory, the migration from one schema to the other should be seamless, but here it’s not the case.

So, from my point of view, you have two solutions :

  • Delete every NotificationPreferenceClass XObject contained in the user profiles (this will reset every user notification preference registered before that) using velocity;
  • Also with velocity, migrate the old XObjects to the new XClass schema (what should have been done automatically)