feat: add copy DataSet to other IEDs

[lorenzhoerburgerbearingpointcom]

What

Adds a copy DataSet action to the DataSet editor. Users can now copy an existing DataSet from one IED to one or more other IEDs in a single operation — the same workflow already available for GSEControl, ReportControl, and SampledValueControl.

Why

When commissioning multiple IEDs with the same or similar data models (e.g., several protection relays of the same type), engineers often need to define the same DataSet in each IED. Previously this had to be done manually for every IED. This feature automates that.

How It Works

Each DataSet row in the DataSet editor now has a folder_copy icon. Clicking it opens a dialog listing all other IEDs in the document, with a checkbox per IED. The dialog shows which IEDs are eligible and why others are not. The user selects the targets and confirms — the DataSet is inserted into all selected IEDs in a single undoable edit.

When Is a DataSet Compatible?

A DataSet in source IED A can be copied to target IED B if all three conditions hold:

1. Matching LDevice + LN path – IED B has a LDevice with the same inst value, and within it the same logical node (LN0, LN) by lnClass, inst, and prefix. This determines where the DataSet will be placed.
2. No name conflicts – IED B's matching LN does not already contain a DataSet with the same name.
3. All FCDAs resolvable – Every FCDA in the DataSet references a valid data pth in IED B. This means IED B must have the referenced LDevice, LN, and the full DO/DA chain must exist in its DataTypeTemplates. FCDAs pointing to non-existing logical nodes are data objects are rejects.

Example

Source – IED_A – has the DataSet to copy:

<IED name="IED_A">
  <AccessPoint name="AP1"><Server>
    <LDevice inst="PROT">
      <LN0 lnClass="LLN0" inst="">
        <DataSet name="DS_Measurements">
          <FCDA ldInst="PROT" lnClass="MMXU" lnInst="1" doName="PhV.phsA" daName="cVal.mag.f" fc="MX"/>
        </DataSet>
      </LN0>
      <LN lnClass="MMXU" inst="1" lnType="MMXU_Type"/>
    </LDevice>
  </Server></AccessPoint>
</IED>

IED_B – ✅ Copy possible – has the same LDevice[inst="PROTO"]/LN0 and an MMXU LN with a matching data model.

<IED name="IED_B">
  <AccessPoint name="AP1"><Server>
    <LDevice inst="PROT">
      <LN0 lnClass="LLN0" inst="">
        <!-- no DS_Measurements yet → copy allowed -->
      </LN0>
      <LN lnClass="MMXU" inst="1" lnType="MMXU_Type"/>
    </LDevice>
  </Server></AccessPoint>
</IED>

After copy, IED_B gains DS_Measurements with the identical FCDA entries.

IED_C – ⚠️ DataSet already exists – already has a DataSet name DS_Measurements in the same LN0:

<IED name="IED_C">
  <AccessPoint name="AP1"><Server>
    <LDevice inst="PROT">
      <LN0 lnClass="LLN0" inst="">
        <DataSet name="DS_Measurements"> <!-- name conflict → blocked -->
          <FCDA ldInst="PROT" lnClass="MMXU" lnInst="1" doName="PhV.phsA" daName="cVal.mag.f" fc="MX"/>
        </DataSet>
      </LN0>
    </LDevice>
  </Server></AccessPoint>
</IED>

IED_D – ❌ IED structure incompatible – has no LDevice[inst="PROT"] at all, so there is no valid location to place the DataSet.

<IED name="IED_D">
  <AccessPoint name="AP1"><Server>
    <LDevice inst="MEAS"> <!-- different inst → no matching location → blocked -->
      <LN0 lnClass="LLN0" inst=""/>
    </LDevice>
  </Server></AccessPoint>
</IED>

Changes

• data-set-editor.ts – copy logic, dialog rendering, compatibility check
• data-set-editor.testfiles.ts – added dataSetCopyDoc
• data-set-editor.spec.ts – added unit test for all three compatibility statuses and the copy edit event

[lorenzhoerburgerbearingpointcom]

Had to update the update-screenshot.yml workflow so that updated screenshots are automatically committed back to the branch.
I ran into slight pixel differences between my local environment and the CI environment, most likely caused by platform-specific rendering (e.g. fonts, OS, browser versions). Because of this, I wasn't able to reliably generate baseline images locally that would also pass in CI.
To ensure consistent screenshot generation and validation, the baseline images are now updated directly within GitHub Actions using the same environment that is used for CI checks.

[noraeb]

Looks good!