Multiple developers have discovered that the reverse keyword, used as part of the for syntax, will not always behave as intended. It is the intention of the syntax to cause the loop to reverse iterate over the members of the collection with no other changes/syntaxes/keywords necessary. However, in the current state, Ranges require the developer to also define the collection in reverse order, which shouldn't be necessary.

With this release, this behavior has been fixed and the reverse keyword now functions as intended for Ranges. As a consequnce of the fix, however, existing workarounds will no longer function. If you have used the "define the range in reverse" trick to workaround the problem, you will need un-reverse the range. Failure to make this change will cause the loop to be skipped entirely.

For example, if you have code that is currently written as:

for (i in 3..1, reverse) {

you will need to re-write it as:

for (i in 1..3, reverse) {

Component Tab and Component Tab Creator End of Life

In the CET 17.0 release in May 2026, Catalogue Component Tab and Component Tab Creator will reach their End-of-Life (EOL) and be retired completely.

As part of the EOL effort,

• All component tab related interfaces will be removed. They will no longer receive bugfixes or be shipped as part of CET abstract/custom builds, and you will no longer be able to reference these classes in your packages. See compile-time changes below under "Component Tab and Component Tab Creator End of Life" section.
• The Component Tab file format (.cmtbxt) will also be retired and no longer be supported starting from 17.0. See runtime/behaviour changes below under "Component Tab File Format (*.cmtbxc) End of Life"

All developers are strongly encouraged to migrate to the new Table of Content (ToC) Toolbox introduced in 15.5 Major as the replacement for the Component Tab - (read more and learn how to migrate or build toolbox with ToC here) [https://dev-docs.configura.com/design-system/cet-developer-guides/catalogue-table-of-contents-with-the-new-ui]

Main MR: [https://git.configura.com/cet/external/base/-/merge_requests/42378]

Ind. Tag storage and migration

Data symbol parts and picklists now follow the new 17.0 core Ind. Tag model. Stable Ind. Tag identity is based on sourceId(), user-modified tag text is stored through the shared UserTagInfoHolder, and legacy picklist tag data is migrated during load so existing user overrides can be preserved across reset-behavior changes and older drawings.

MR: Ind. Tag migration and restoration changes

Data-symbol option-special migration

Data-symbol product parts also participate in the 17.0 option-special storage split. Before 17.0, DsPart option specials were read from the shared owner-level PartSpecialHolder using data-symbol-specific combined keys. In 17.0, those option specials belong in the per-part OptionSpecialHolder introduced in cm.abstract.part, and DsPartSpecialMigrator exists to translate older DsSpecOption keys into the new holder layout.

If your catalogue package has older drawings that must preserve DsPart option specials or additional options, you need to opt in to that migration flow during load.

Office electrical support has moved out of the shared package

cm.abstract.office no longer provides the older panel-frame electrical object framework from electrical.cm. Instead, the package now depends on cm.abstract.pathing and exposes AOElecNode as a small office-level building block for packages that want to implement a routed electrical system.

The new 17.0 custom.fika electrical system is the reference example for that new routed architecture. Rather than asking PanelFrame and PanelJunctionSnapper for EOPosition or EORange data and applying ElectricalObjects directly, Fika defines electrical snappers, routing nodes, and A-star path finding on top of AOElecNode and cm.abstract.pathing.

For most manufacturers, the lower-effort migration path is not to fully adopt the new Fika routing model. If your package already relies on the old office electrical interfaces, the practical migration path is to copy the removed interfaces and supporting logic into your own package-owned classes and continue using that model there.

The abstract part layer now follows the new core Ind. Tag model. The calculation Ind. Tag column can split rows by actual user-entered tag text, only treats true user overrides as adjusted values, and applies row-level Ind. Tag adjustments to each underlying part. A post-merge hook also repairs pre-17.0 adjustment keys when older drawings are loaded.

MR: Ind. Tag migration and restoration changes

ProdPart has also been expanded with first-class support for option additions, option import, and option-level customization state. Those changes provide the part foundation for the new query import workflow in cm.abstract.part.query, where imported option items can be dragged into the query dialog and applied as additions or special overrides.

CET 17.0 also changes where option specials live at runtime. Before 17.0, both PartSpecial and OptionSpecial data were stored together in the snapper-level PartSpecialHolder under cSpecialHolderKey, and option-special lookup depended on a combined part-and-option key. In 17.0, option specials move into a separate per-part OptionSpecialHolder, stored on the owner under a key built from optionSpecialHolderPropKey(part) and the part's sourceId(). That split is what makes stable option identity, inserted-option ordering, and per-part option-special migration possible.

Because older drawings still load old option specials from PartSpecialHolder, packages that need backward compatibility must opt in to the new migration helpers such as ProdPartSpecialMigrator and DsPartSpecialMigrator during their load/migration flow.

Product-part import overview

CET 17.0 adds a new product-part import layer in cm.abstract.part.import. These classes specialize the new core importer framework so SIF, PMX, and OFDA XML imports can create ProdPart instances instead of plain Part instances.

The most important new behavior is in SIF and OFDA XML import. ProdPartSIFImporterEnv can now build SpecOption data during import, and OFDA XML import can now route option tags into ProdPart through new shared option-import hooks.

This package is also the bridge used by the query import UI. cm.abstract.part.query now returns these environments from ProdPartQueryDialogBehavior.getImporterEnv(str suffix), so imported product parts and product options flow through the same importer framework as the core query import path.

Product-part option import support

cm.abstract.part.query adds the product-part and option-specific part of the new 17.0 query import workflow. Together with the base dialog changes in cm.core.part.query and the underlying option/customization changes in cm.abstract.part.ProdPart, product-part query dialogs can now import product parts and option items, drag option items into the query grid, and create option additions or overrides in addition to the existing option-special workflow.

CET 17.0 splits the PMX code that used to live entirely in cm.abstract.pmx into two layers. cm.abstract.pmx is now the abstract/export-facing package: it keeps the PMX order exporter, package initialization, test hooks, and local file-move/debug helpers. The reusable PMX database wrapper types, PMX data-definition objects, constants, and .NET bridge code have been moved into the new shared package cm.core.pmx.

That means most compile-time migration work is import and type rerouting. If your code previously referenced PMX model/database types through cm.abstract.pmx, update those references to cm.core.pmx instead. If your code used PMX import helpers such as PMXFilePartSource or ItemDataConverter, those APIs were not moved into cm.core.pmx; they now live in cm.core.part.import.

The ItemData option payload also changed shape during that extraction. The old abstract-only optionsSeq storage is gone in 17.0; the shared cm.core.pmx.ItemData uses a single canonical options array for option generation, appending through operator<<, exporter insertion, and part initialization from PMX data.

Project information drop-down values now preserve display labels

cm.abstract.projectInfo now stores and restores project-information drop-down selections in a way that preserves the selected item's label as well as its key.

This fixes a visible behavior issue in paper view and other text-driven outputs where fields such as terms of delivery, delivery method, terms of payment, and delivery time could show only the stored numeric/key value instead of the human-readable label.

Improved the texture mapping of many wall symbols such as arced walls, windows and curtains.

DcSIFExportEnv no longer has ambiguous constructor overloads

custom.dataCatalog.builder removes the ambiguous DcSIFExportEnv constructor overload pair that previously accepted the same overall argument set with catalogCodeOverride and useInFile in conflicting positions.

This fixes a compile-time problem for downstream subclasses calling super(...), where CET could report an ambiguous function error unless the caller forced the overload with a positional null.

Fika migrator overview

custom.fika is not where the shared migrator framework is defined, but it is an important example package for the 17.0 migration story. It shows how a catalogue package with older custom Part key history can opt in to the new PartSpecialMigrator load flow by exposing a snapper-level partSpecialMigrator prop and returning a package-specific migrator.

In Fika's case, FikaDsPartSpecialMigrator extends DsPartSpecialMigrator and overrides oldPartSpecialsKey(Part part) so older Fika drawings can still find part and option specials that were stored under pre-17.0 key formats.