I've largely diagnosed this issue and created a workaround. Here is the problem as I understand it:
Core Akeneo 2.3 has updated the MeasureBundle to use a new MeasureManager service to store and load the measure configuration. In addition, the measure config is stored without the top-level 'measures_config' node and is now just an array of the families.
So, during the MeasuresCompilerPass run, you must redefine the call to the MeasureManager to set the config:
However, this will not fix the issue as the MeasureManager expects the data as an array of the families and the ExtendedMeasureBundle currently generates and reads this data with the 'measures_config' top node.
In my local fix I simply overrode the MeasureManager to add this node when reading the config array, but the real fix is probably to update the ExtendedMeasureBundle to drop the 'measures_config' node from the config generation and to use the MeasureManager to retrieve the measure data.
I've largely diagnosed this issue and created a workaround. Here is the problem as I understand it:
Core Akeneo 2.3 has updated the MeasureBundle to use a new MeasureManager service to store and load the measure configuration. In addition, the measure config is stored without the top-level 'measures_config' node and is now just an array of the families.
So, during the MeasuresCompilerPass run, you must redefine the call to the MeasureManager to set the config:
However, this will not fix the issue as the MeasureManager expects the data as an array of the families and the ExtendedMeasureBundle currently generates and reads this data with the 'measures_config' top node.
In my local fix I simply overrode the MeasureManager to add this node when reading the config array, but the real fix is probably to update the ExtendedMeasureBundle to drop the 'measures_config' node from the config generation and to use the MeasureManager to retrieve the measure data.