Breaking behaviour: ensure that xproperty default values are respected

Hi everyone,

yesterday as part of my BFD I started to investigate on Loading... and while discussing with @tmortagne it appeared that the problem is wider than just REST API: apparently the default values of our xproperty are only used when using the xobject editor. It means that if you create a script to insert an xobject with a property containing a default value, the contract won’t be respected and the default value won’t be used.

It should be a no-brainer to fix this behaviour and to ensure default values are always respected when instantiating new properties. However it’s a behaviour change compared to what we have now, and it might have consequences: for example, we know that it impacts XWikiRights xobject, so we can imagine that some scripts are creating XWikiRights xobjects without setting the allow field to any value, assuming it would be denied. Fixing the bug to respect the default value would change the behaviour to properly set the allow field to allowed. This is a single example: AFAICS boolean properties and list properties are impacted by this. To my knowledge, default values are not much used in XS in our objects, but it’s probably used in extensions and custom code.

So this proposal is about fixing this behaviour in 16.6.0RC1 without any backport. If we consider it’s too dangerous we might imagine providing a configuration option to disable this, but I’m really not a fan of this idea.

So what do you think? Should we fix this or not?

+1 to take into account the configured default value in BooleanClass#newProperty().

This proposal is also about ListClass (the other type of properties where we have the concept of default value), right ? Note that in practice ListClass means DBListClass, GroupsClass, LevelsClass, StaticListClass and UsersClass which all inherit from it (but I can’t remember a single use case where a list property had a default value).

Yes it’s about fixing the behaviour for all properties.