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.

Removed file electrical.cm

The old public office electrical framework was removed from cm.abstract.office. If your package depends on these interfaces today, the expected migration path is to copy the removed interfaces and any needed implementation from the old office electrical system into your own package, then update your package code to reference those local types instead of the deleted cm.abstract.office ones.

Removed: public class AbstractPointEOPosition extends EOPosition
Removed: public class PointEOPosition extends AbstractPointEOPosition
Removed: public class LineEOPosition extends EOPosition
Removed: public class EORange extends EOPosition
Removed: public class PanelFrameElectricals extends CorePropObj
Removed: public class InsertElectricalObject extends ToolAnimation
Removed: public class ElLinkSnap extends LinkSnap
Removed: public class ElectricalConnection extends CorePropObj

class PanelFrame

The old panel-frame electrical extension points are gone from cm.abstract.office. Packages can no longer plug electrical behavior into PanelFrame through the removed ElectricalObject / EOPosition flow unless they recreate that API in their own package.

Removed: extend public PanelFrameElectricals electricalData()
Removed: extend public EOPosition[] electricalPositions(ElectricalObject z)
Removed: extend public bool apply(ElectricalObject z, EOPosition pos, ElectricalAction action)
Removed: extend public bool remove(EOPosition pos, ElectricalAction action)
Removed: extend public electricalAction allow(ElectricalObject z, EOPosition pos, bool replace, bool toogle)

class PanelJunctionSnapper

The old junction routing hooks were also removed from the shared office package. Packages that still use the old electrical model should move these hooks into their own junction classes.

Removed: extend public PanelJunctionElectricalConnect[] electricalConnects(bool visual=false)
Removed: extend public EORange[] routingPositions(ElectricalConnection z)

package dependencies

cm.abstract.office now imports cm.abstract.pathing, and the corresponding abstract extension adds cm.abstract.pathing as a package dependency. This matters if you choose to adopt the new routed electrical model used by custom.fika, but it is not required just to preserve an older package-owned copy of the removed electrical interfaces.

Added/important usage: use cm.abstract.pathing;

There is no default shared office electrical insertion/routing behavior anymore

Packages that previously relied on the old InsertElectricalObject animation and PanelFrame callbacks will not get equivalent behavior automatically in 17.0. If you do nothing, that shared behavior is simply gone.

For existing manufacturer packages, the expected behavior-preserving migration is usually:

• copy the removed office electrical interfaces and behavior into your own package
• update your panel and junction classes to call those package-local interfaces
• keep your existing placement/routing model unless you specifically want to redesign around node/path routing

custom.fika shows a different, more structural 17.0 option:

• FODataElecSnapper exposes appendElectricalAlternatives(...), getSnappingNodes(...), getAvailableNodes(), getNeighborNodes(...), appendNodesToPath(...), and alreadyRoutedTo(...)
• FOElecNode subclasses AOElecNode and delegates those routing decisions back to the owning electrical snapper
• FOElecPathAnimation and FOElecPathFinder replace the old insert/apply/remove workflow with routed path creation

That Fika approach is useful when you want the new routed electrical system, but it should be treated as a redesign path, not as the default migration expectation for every manufacturer package.

This change is closely related to the new electrical system introduced in custom.fika, but the reusable office-side surface in 17.0 is intentionally much smaller: cm.abstract.office now provides the shared node type, while product packages own the actual electrical-system behavior.