1.251

Examples of information that can be saved on the RunOutput:

• The list of all used components, with the hash and UUID
• The list of all parameters and their values (from the run context)
• Additional information such as the pool version UUID

To prevent new pool configurations from being too unrelated to central requirements, it is now possible to reference the pool configuration of a reference project. The reference configuration is used instead of the individual configuration. For this purpose, a special XML syntax was introduced. Example:

<?xml version='1.0' encoding='utf-8'?> 
<pool-config name="Example_Pool" uuid="ab60c10a-fd2a-4d1a-b6f9-7c16cbbc4a81" is_subordinate="0">
<!-- new syntax: reference to uuid of other pool config -->
<inherit-config pool_uuid="7a46a3e0-a0f8-4f1f-b36b-912f2854a3f0" pool_name="Reference project"/>
<description>Pool description...</description>
</pool-config>

The syntax indicates the UUID of the reference project. Modifications to the reference project are “inherited” to the child project. It is only possible to reference one pool configuration and no other definitions can be written. That means, e.g. in the example above, it is not possible to define an additional group in “Example_pool”.

The --prefetch-blobs option was added to the loco2-admin sync command. This allows the installation to fetch all blobs during the sync and get an estimate of how long the sync could take for all PROD data.

A configuration flag was added to disallow_pure_offsite_user_creation in the secondary service config. This makes it possible to prohibit pure offsite users (only present on the offsite/secondary service) from being created on the secondary service. In such case, users would need to be created via the main service.

Note: The default is to allow the creation to pure offsite users.

This makes it possible, e.g. for components that are saved in a generic pre-processor format to automatically be converted into different solver formats after editing and automatically be saved in SCALE.sdm.

In Model, the file name of a component is retrieved based on a conditional name scheme, which includes certain conditions based on the context in which the component is used in the client.

For SCALE.search, the component file name must be retrieved from the service, where such conditions are not explicitly set. To circumvent this issue, the file name is now computed for each name scheme at its defined alternatives and then added to the component data in the SCALE.search index.

Users have attachments on many of the components that they use during assembly. The existing template API was extended so that these attachments can be used as data in the assembly process. The template API is now able to provide the attachment information of the components via explicit queries during assembly.

• In local assembly, the template retrieves the attachment information from the local client.
• In remote assembly, the template queries the attachment data via the server API.

In the past, the modification/creation date for components in the grid and the date for assembly starts were displayed as “X days ago”. This was too imprecise for certain use cases. The information is now displayed as an exact date.