The following class has changed: modify notice class property has been set. See this help center article on Modify Notice behavior.

// Class: cm.core.category.CustomCategoryRecord
Old: public class CustomCategoryRecord extends CategoryRecord
New: public class CustomCategoryRecord extends CategoryRecord : modify notice

The following classes below have changed: modify notice class property has been set. See this help center article on Modify Notice behavior.

// Class: cm.core.partTag.PartTagCategory
Old: public class PartTagCategory
New: public class PartTagCategory : modify notice

// Class: cm.core.partTag.PartTag
Old: public class PartTag
New: public class PartTag : modify notice

Removal of ensureSettings() call in scheme apply

In 12.0, before scheme apply, to make sure that the props are ready on the target object, we needed to do ensureSettings as prop exposure is typically done there. But it could be very heavy when applying to a lot of snappers, as we don’t need to build the settings, all we need is to make sure the props are exposed.

To counter this, we introduced a validation system for the propDefs, that when called with a certain flag, will call ownerReExposePropDefs to make sure the propDefs are updated.

// In cm/props/propObj.cm: 
/**  
 * Invalidate defs.  
 * Runs validation when propDefs() is called.  
 *   
 * You can for example call this with #reExpose to reexpose registered propDefs  
 * instead of doing it in ensure settings. (implemented in corePropObj)  
 */ 
 final public void invalidatePropDefs(symbol k, Object env=null) {
     ?symbol->Object invalidateDefEnv = propData.?get(cInvalidateDefEnvKey);
     init? invalidateDefEnv();
     invalidateDefEnv.put(k, env);
     if (cInvalidateDefEnvKey !in propData) fastPut(cInvalidateDefEnvKey, invalidateDefEnv);
}  

The issue comes when the propDefs were never exposed/registered before, then there would be nothing to reexpose. In our fix we will need to call ensureSettings the first time if nothing has ever been exposed or registered before.

In the future we plan to have a better fix for this to mitigate the risk of possible calling ensure settings unnecessarily too much.

Some common Q&As regarding the issue:

InitFromPropsScheme doesn’t work anymore, new snappers inserted from toolbox does not get the properties in my selected scheme. What should I do?

We have verified this as a core issue and are working on a fix. If you would like to test it out, try the following:

1.In the constructor of your snapper/object, at the end of it, call ensure settings
2.Insert snapper and see if the problem is resolved. If it is, just wait patiently while the fix is getting tested and merged, otherwise please contact dev support.

I don’t want to wait, there must be something else I can do?

Alternatively, you can do ownerRegisterExposure on your snapper init and loaded1, then your problem would go away immediately.

Change for executePushProps() in PropsSchemePushVisitor

In 12.5, we have refactored the executePushProps() in PropsSchemePushVisitor and PsLayoutPushPropsVisitor to better handling scheme apply for exposed sub objects of a receiver. The change will no longer require exposed sub objects to call pushProps() in its owner.

However, this change could potentially break scheme apply for unexposed sub objects that relied on pushProps(). This is because executePushProps() now calls pushProp() instead of pushProps().

To adapt to this change, we would like to propose using push behaviors for sub objects, here is a step by step guide to setup push behaviors: https://support.configura.com/hc/en-us/articles/14830845427351-Using-PropsSchemes

Using push behaviors would also mean you no longer need to extend pushProps() method just to call pushProps() for sub objects. However, if you encountered any problems on setting up push behaviors, please contact dev support.

Potential issue when init custom scheme on CET start up and the workaround

If you have a custom scheme that is built based on a published scheme design file (*.cmpsl), there is a chance where your scheme might not get init/registered properly if the following scenario matches:

• Catalogue Browser extension is turned on, and
• Catalogue of the published scheme design is turned on (before embed) in Catalogue Details, and
• The published scheme design is activated

If all 3 scenarios mentioned above matches your setup, it is very likely that your custom scheme might get overriden by the Catalogue Scheme registered from Catalogue Browser during CET startup. Here are a few steps to resolve this:

• If the scheme design is not meant to be used in Catalogue Browser, deactivate the scheme design through creator and republish it again.
• In your custom scheme class, when calling dsLoadLayout(), always make sure to pass in activeOnly=false, so we can always get the scheme design regardless of its active status.
• If you are not using Catalogue Browser at all, turning it off should directly avoid this issue.