1.230

• It is now possible to add sub-components to a multi-component during the edit process.
• It is now possible to assemble multi-components. The assembly logic is as follows:
  • The multi-component itself can contain attribute values, which should automatically be passed to the sub-components.
  • The sub-components can contain additional attribute values. The attribute values coming from the multi-component could also be edited.
  • Only sub-components with attribute values valid for a RunConfig should be contained in it.
  • The multi-component itself is not a real component, meaning it does not contain any explicit file, so it should never be part of a RunConfig. Only the matching sub-components can be part of a RunConfig.
• It is now possible to edit multi-components with editors from the apps pool.
• It is now possible to synchronize multi-components and sub-components between a new client and a new server. The synchronization works for private, public and live versions.
• The preprocessor component was converted into the new multi-component. Note: This feature only relates to the backend of the preprocessor component. The GUI concept is contained in a separate issue.
  • not only two, but multiple components are connected.
  • none of the components are a “parent” component.
  • attributes can be set on both the top level (the multi-component) and also on each individual sub-component.
  • if an attribute value is set on the multi-component, then the attribute is automatically propagated to all of its sub-components.
  • the properties of a multi-component are essentially the same as when all of the sub-components are “multi selected”.

The PoolEntryMetadata was also extended to provide access to the history comment. This can be used, for example, to detect changes in attributes or the short description between the versions and automatically include this information in a history comment that might be provided by an external app script.

Parameter:

• pool_version_uuid: mandatory
  • unique identifier

Return value:

• Format Json
• List with following properties:
  • UUID of the assembled run
  • Attributes of the assembled runs
  • Date created/modified (i.e. timestamp of the assembly)
  • Run name
  • Further properties can also be provided

Parameters:

• assembled_run_uuid: mandatory

Return value:

• List of all attachments with the following properties
  • Description: Name of the attachment
  • Attachment key: Unique identifier
  • Blob-hash

Parameters:

• attachment key: Unique identifier of the attachment (within the assembled run UUID)
• assembled_run_uuid: UUID of the assembled run

Return value:

• Content type (HTTP header field)
• Content of the attachment => data stream

When editing components with an external editor, it is possible to create or modify a metadata file that defines data like the attribute, short description or history comment of a component. In the past, these changes were directly applied when closing the edit window. This behavior has been improved. Now the changes are transferred to the transient components in the edit window, so that the changes can be reviewed before applying them.

This fix relates to the Changes area of the Properties view. In the past, if a user selected multiple versions of a component group, then the Properties view froze and prevented the compare view from being loaded. This behavior has been fixed.

This fix relates to the Attachments area of the Properties tab. In the past, the entire path of ISO-MME uploads was displayed here. This behavior has been fixed. Now only the attachment’s name is displayed.