We’re updating the behaviour of AQS Join queries to ensure that all join attributes are exported correctly in a particular scenario.

This will change the output of the Export API endpoint for some AQS Join queries. However, rest assured that none of your saved queries will be affected!

Who will be affected?

Anyone who uses:

• the Data Explorer’s export feature in Alloy Web
• the Export API endpoint

Details

The change will only affect AQS Join queries where all the following are true:

• the queried design contains a Link attribute to an interface
• the query includes a join attribute from the interface
• the query includes one or more join attributes from a child design/interface that implements the interface

Currently, in this scenario, the join attributes from the child design/interface are incorrectly included within the interface’s path group. As a result, these join attributes are omitted from the export files because their paths are invalid.

The change will correct this issue. Therefore, if you regularly export joined data, be aware that export files may start to contain attributes that were missing before.

Expected release

30th May 2024 as part of the Alloy v2.59 release.

Overview

A workflow action group lets you define a series of actions that can be stored on its own and referenced in other workflows. A workflow within a workflow, if you will.

However, now that manual workflows have parameters, they can provide this functionality in a better way. Therefore, for simplicity and consistency, we're removing workflow action groups and updating manual workflows so they can be referenced within other workflows.

Who will be affected?

Users who create and edit workflows via the Alloy API.

Details

You'll be able to reference a manual workflow in your workflow by creating an action whose design implements designInterfaces_workflowManualTrigger:

• The parametersDesignCode property must be set to the design code of the manual workflow.
• The new OutputActionId property must be set to the ID of the action that represents the final output of the referenced manual workflow. This output will be passed on to the next action in your workflow.

While it will be possible to chain multiple workflows (a workflow that references a manual workflow that references a manual workflow...), rest assured that Alloy will stop you from creating any circular references! 😮‍💨

Parameters

If the referenced manual workflow requires any parameters, you can supply them in the parameters array when adding/editing the relevant action in your workflow.

Depending on the type of WorkflowComputedItemAttributeWebModel used, you can supply values computed during your workflow, or pass on any parameter values that were supplied to your workflow when triggered.

Removed endpoints

All WorkflowActionGroup endpoints will be removed from the Alloy API.

Expected Release Date

26th October 2023 as part of the Alloy v2.52 release.

Overview

Alloy’s robust Permissions system gives you fine control over who has read/write access to most of the objects in your Alloy database (e.g. designs, layers, workflows).

To take this a step further, we introduced Access Policies. These are simple rules defined per design/interface, which ensure that users can only access items that can be traced back to them. For example, making job items only accessible to users who are members of the job’s allocated team.

While Access Policies work well in principle, the current implementation unfortunately comes with too much of a performance cost.

Therefore, Access Policies will be removed in the next Alloy release, to be replaced with a better implementation at a later date.

Who will be affected?

No active customers are currently using this feature, so we expect its removal to have zero impact.

Details

The /api/access-policy/ endpoints will be removed from the API. Any remaining access policies will be deleted.

Expected Release Date

23rd February 2023 as part of the Alloy v2.44 release.

Context

As you may be aware, we have been facing an issue with importing geometry data through the Gateway using the Alloy Web Client. Currently, when a coordinate system is selected, all rows with geometry in an import will return a warning and will not be imported correctly. This has been due to a change to a third-party service which supplies projection settings used by the Alloy Web Client.

This is an ongoing issue and has not yet been resolved, however, in an effort to allow a workaround for this issue, we have altered the coordinate system selection to display the conversion (proj4) string.

Workaround

To select your data file's coordinate system, click the magnifying glass icon to bring up the picker and select from the list.

This populates the Coordinate system text box with the configuration string for your selected coordinate system. This string is currently being formed incorrectly and removing the text +type=crs at the end of the string, will resolve this import issue.

We understand that this solution is not ideal, and are working on a long-term fix, but in the meantime, we have introduced this change to allow you to continue importing your data.

Overview

We are making a temporary change to the behaviour of how the results from an AQS Query Data Source are displayed in custom reports. This change will affect the display in controls when linking to multiple items to make this work consistently across all attribute types.

This change is being made to prevent report generation from failing under certain conditions described below.

Who will this affect?

This change will affect anyone using the AQS Query Data source with join attributes within the Report Builder to build custom reports.

Details

Previously, when an AQS Query resulted in multiple matched items for join attributes, this would be displayed as X Items into the resulting table cell in the report. However, since all entries in a table column must be of the same type, this would only work for String attributes (since the entry X Items is also a String) and would result in an error for other attribute types with the report failing to generate. 

From now on, resulting cells will show a single item attribute result, similar to the current behaviour of the single join result. If multiple values are matched, only the first attribute of the first item will be displayed. 

Example

Let's assume there is a project containing 4 job tasks. If the user would create a custom report using an AQS Query data source rooted on Projects and linking to Jobs via the Tasks Attribute (Project DS -> Tasks to Jobs DS -> Title). If a Table control was then added to the layout based on this data source, the display of the data in this table will change following this change. 

Before Change

Previously, the table would have shown 4 Items in the joined Tasks and Title column.

After Change

However, from now on this would display one of the job titles e.g. JOB-9.

Note

If you would like to continue using this aggregation, this can be achieved by using a Join Data source rather than an AQS Query Data source.

Expected Release Date

30th September 2021

Note

Due to a technical error, this post is being announced after the changes in Phase 1 were issued. 

Overview

When first designing Alloy, we anticipated the need for an item setting that would allow versioning. With this setting enabled, each change to the item would create a new version of the item with only the most recent item being visible in the application. While we still believe this function may hold value in the future, maintaining the feature in the application offers very little benefit over the item audit logs. Instead, the item versions consume storage space unnecessarily when enabled on designs. 

We have therefore taken the decision to remove item versioning for the time being. 

Who will this affect?

The change to remove item versioning will not impact the functionality within the system and is being made to improve performance for customers with large numbers of items. 

This work will mark the properties and endpoints marked as Obsolete to be removed at a later date. If this can cause a problem for API users, we urge you to take action during the time provided before removal as any integrations relying on obsolete properties may cease to function.  

Phase 1

Details

Both DesignWebModel and DesignInterfaceWebModel will not have the versioned property being returned anymore. It was already advertised as optional in the response and it is thus not meant to cause any problem.

The start and end properties ofItemWebModel and ReconstructedItemWebModel are now obsolete and will always return respectively 0000-01-01T00:00:00Z and 9999-12-31T12:59:59Z.

The DesignEditWebRequestModel and DesignCreateWebRequestModel will not accept the versioned property anymore. If the property is passed, it will be ignored.

The ReconstructedItemDeltaWebModel optional properties start and end will not be returned anymore.

The GET api/item-version/{itemId} and the GET api/item-version/item/{id} are now obsolete and will be removed as part of phase 2.

Phase 2

The start and end properties of ItemWebModeland ReconstructedItemWebModel  that were obsoleted during phase 1 will be removed.

The GET api/item-version/{itemId} and the GET api/item-version/item/{id} that were obsoleted during phase 1 will be removed.

Phase 1 Expected Release Date

3rd September 2021

Phase 2 Expected Release Date

March 2022

Overview

We are making changes to some of our endpoints in order to become fully OpenAPI 3.0 compliant. Additionally, we will be adding Redoc under the /docs path to provide an even easier way of navigating our API definition and explore models that use discriminators.

Who will this affect?

There are several changes to various endpoints as detailed below. None of these changes are expected to be a breaking change and the current method of calling these endpoints will remain compatible.

There will however be a Phase 2 of this work in which we will remove any obsolete endpoints and properties. API users should complete any transition to the new endpoints before the Phase 2 date to avoid issues.

Details

Delete Endpoints

The following endpoints will change to have a query parameter named signature to pass the signature. Passing the signature in the body will be obsoleted and removed in Phase 2:

DELETE api/access-policy/{code}/rule/{id}
DELETE api/custom-report/{customReportCode}/data-source/{code}
DELETE api/custom-report/{customReportCode}/document-definition/{id}
DELETE api/design/{code}/attribute/{attributeCode}
DELETE api/design/{code}/interface/{interfaceCode}
DELETE api/workflow-action-group/{code}/action/{id}
DELETE api/workflow/{code}/action/{id}

User Group Endpoints

There are 2 new user group endpoints to add and remove users from a user group:

POST api/user-group/user/add
POST api/user-group/user/remove

The following two (current) endpoints will be marked obsolete and removed in Phase 2; note, these will no longer be visible through the swagger documentation.

POST api/user-group/user
DELETE api/user-group/user

Role User Endpoints

There are 2 new role endpoints to add and remove users from a role:

POST api/role/user/add
POST api/role/user/remove

The following two (current) endpoints will be marked obsolete and removed in Phase 2; note, these will no longer be visible through the swagger documentation. 

POST api/role/user
DELETE api/role/user

Role Group Endpoints

There are 2 new role endpoints to add and remove groups from a role:

POST api/role/group/add
POST api/role/group/remove

The following two (current) endpoints will be marked obsolete and removed in Phase 2; note, these will no longer be visible through the swagger documentation. 

POST api/role/group
DELETE api/role/group

Expected Release Dates

Phase 1 : 29th September 2021

Phase 2 : 31st March 2022

Overview

In order to improve the accessibility of Alloy Meshes, we will be adding support for Open API JSON and endpoint documentation. Following a detailed review of the exposed endpoints and data models, we will also be acting to implement the following deprecations to provide better consistency between naming and conventions with the Alloy Core, Extended and Forge API's. Finally, we will be making changes to the way in which the security token is passed to the Meshes to improve security. 

Security token to be removed from query string

We will no longer be accepting the token parameter which represents an Alloy API token on the query string, this should be passed via the HTTP headers in all future requests using the same key of token.

Example CURL before:

curl -X 'POST' \
  'http://localhost:3000/aws-iot/update-device?itemId=abc?token=123' \
  -H 'accept: application/json' \

Example CURL after:

curl -X 'POST' \
  'http://localhost:3000/aws-iot/update-device?itemId=abc' \
  -H 'accept: application/json' \
  -H 'token: 123' \

MeshResponseWithItemWebModel renames property itemResponse to item

The following meshes are expected to return a response which includes an item payload under the property itemResponse.

• alloy-push-mayrise-notice-mesh
• json-push-alloy-mesh
• telensa-fault-push-alloy-mesh

This property is being renamed to item but we will continue to return itemResponse until the date specified below for Phase 2. 

Example response before:

{
  "itemResponse": {
    "itemId": "af32ef...",
    ...
  }
}

Example response after:

{
  "itemResponse": {
    "itemId": "af32ef...",
    ...
  },
  // we will duplicate the data in the recommended item property
  "item": {
    "itemId": "af32ef...",
    ...
  },
}

Risk calculation mesh to remove itemsResponse property

The risk calculation mesh alloy-push-risk-calculation-mesh is removing the itemsResponse property as it was not correctly indicating the success of the response model, it isn't required and will therefore be removed as part of Phase 1 changes. 

When do these changes take effect?

The above changes will be rolled out in June 2021, with deprecations finally removed in January 2022 with the following expected release dates: 

Expected Release Date

Phase 1: June 24th 2021

Phase 2: February 24th 2022

Overview

In an earlier announcement titled Removal of Item Title, Subtitle and Geometry properties (Phase 2), users were advised to update export AQS query to return the above attributes if they need them for their exported items. As part of these changes, we are making the ExportGeometry option obsolete as this can now be specified through the inclusion/omission of the geometry attribute in the query. 

Who will this affect?

Users querying the data with geometry via the API will be affected by the change.

Details

We are now making ExportGeometry optional and obsolete on the ExportWebRequestModel and it will be removed in due course in favour of requesting attributes_itemsGeometry as part of the export AQS attributes.

Expected Release Date

October 29th 2020