Overview

In order to support setting the page orientation of Custom Reports Flow documents, we have added a new property to the CustomReportDocumentDefinitionFlowWebModel called orientation. The property has also been added to endpoints which create or edit the Flow documents definition.

Who will this affect?

This change affects users who are creating and editing custom report flow documents through the API.

Details

Responses that use the CustomReportDocumentDefinitionFlowWebModel will now need to include a definition for orientation. 

Requests to the following endpoints will now require a value for orientation:

POST api/custom-report/{customReportCode}/document-definition 
PUT api/custom-report/{customReportCode}/document-definition/{id}

The orientation property can be one of two options:

• Portrait
• Landscape

For example, creating a Flow document via POST /api/custom-report/{customReportCode}/document-definition

{
  "name": "ExampleDocument",
  "documentDefinitionInfo": {
    "discriminator":
        "CustomReportDocumentDefinitionFlowWebModel",
    "orientation": "Portrait",
    "controls": [...],
    "visualizations": [...]
  }
  "signature": "..."
}

Expected Release Date

9th December 2021

Note

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

Overview

We have added a Context property to Alloy items and it will now be visible as part of all calls that get or list items.

Users will not be able to edit or delete system items, those with Core and Module context property.

This is to avoid any issues where items that Alloy expects to be present, are unexpectedly removed.

Who will this Affect?

This change will affect users who access items via the API or manage integrations.

Details

Example of GET /api/item/{id} for working days Core item

{
  "item": {
    "itemId": "5c800cc32d14711a9cc642f4",
    "designCode": "designs_workingDays",
    "collection": "Live",
    ...
    "context": "Core",
    "attributes": [...]
  }
}

There has been no change in terms of item creation and users cannot pass an item context on items create or edit. All user-created items will automatically have context set to Customer. 

For example, creating holidays item via POST /api/item

{
  "designCode": "designs_holidays",
  "collection": "Live", 
  "attributes": [
    {
      "attributeCode": "attributes_holidaysName",
      "value": "May holiday"
    },
    {
      "attributeCode": "attributes_holidaysStartDate",
      "value": "2021-05-03"
    }
  ],
  "locked": false
}

Will return response that includes "context": "Customer"

{
  "item": {
    "itemId": "607d5420959e583ad874fc58",
    "designCode": "designs_holidays",
    "collection": "Live",
    ...
    "locked": false,
    "context": "Customer",
    "attributes": [...],
    "signature": "607d5421959e583ad874fc5d"
  }
}

System items delete and edit is forbidden

When trying to delete or edit system items, the API will now respond with a 403Forbidden response, e.g. for working days standard item 5c800cc32d14711a9cc642f4 as above swagger responses are as follows.

Expected Release Date

3rd September 2021

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

Overview 

As part of our ongoing work to provide greater clarity around system limits we are defining the limits when importing data. By defining these limits, we will be able to provide improved error handling and feedback. 

Who will this affect?

This change will affect anyone using the Alloy imports to perform large scale imports. Note that the limits are defined with some headroom such that imports with records counts over the set limits that may have previously passed will now fail.  

Details

Data imports with no parent links configured will be limited to 1,000,000 records.

Data imports with any parent link configured will be limited to 500,000 records. This is due to the extra processing and storage overhead required to connect items as part of an import.

To import more than the above specified items in the system, it will be necessary to stage the process and execute multiple imports.

The parent links mentioned are ones that can be configured in the "Parents" section within the Gateway module:

Or for API users, by using the parents property in the ImportValidateWebRequestModel:

{
  "designCode": "designs_test",
  "collection": "Live",
  "mode": "Insert",
  "settings": {
    "attributes": [],
    "networkReferences": [],
    "parents": [
      {
        "dodiCode": "designs_parent",
        "attributeCode": "attributes_link",
        "matchHeader": "MyHeader",
        "matchAttributeCode": "attributes_random"
      }
    ]
    "discriminator": "ImportSettingsDataWebModel"
  },
  "signature": "60e623e00000000000000000"
}

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 a change to the password policy to ensure at least one special character is present when setting an Alloy password. This will increase password complexity in order to prevent unauthorised access to your Alloy account.

Who will this affect?

Current passwords will remain valid even if they do not contain a special character, so this won't impact existing users immediately after release.

However, this will apply to existing users when they change or reset their passwords. The change will also affect new users setting up an Alloy account for the first time.

Details

New user passwords, and existing users changing or resetting passwords, will need to include at least one special character. A special character is a character that is not an alphabetic or numeric character, e.g. @&*[].

Expected Release Date

28th October 2021

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 

As part of our ongoing work to provide more detailed messaging from our API, we will be updating our responses to contain information regarding how close the caller is to reaching this limit in response headers.

Who will this affect?

This change will only affect users that are likely to exceed the API rate limit by providing them with greater feedback when this may occur. 

Details

As described in a previous post, our API will limit the number of calls that a user can make in line with our rate limiting policy.

We will be updating our responses to contain information regarding how close the API caller is to reaching this limit in response headers, for example:

X-Rate-Limit-Remaining: 99
X-Rate-Limit-Reset: 2021-03-16T11:08:08.0232125Z

This message informs you that if you make more than another 99 requests before the specified time, you will be subject to rate-limiting.  When the limit is exceeded, requests will then fail with HTTP 429, and there will be a response header letting you know how many seconds to wait until you will again be able to make requests, for example:

Retry-After: 15

Note that these are the standard headers recognised for HTTP rate limiting.

Expected Release Date

July 29th 2021

Overview

AQS expressions now support the ability to run queries with conditions on an item level count.

Who will be affected?

All existing users will be able to take advantage of this feature through the newly added AQS Count node.

Details

An item level count allows to have a condition on the number of items connected through a link attribute being equal, greater than, etc. to the value of another attribute on the same item.

Example Use Case

As an example, we can consider a query that wants to fetch the title and subtitle of all projects that are over capacity. That is all projects that have a number of tasks greater than or equal to their capacity, contained in attribute attributes_projectsCapacity_60464441c14e5d000ad7e47.

{
  "type": "Query",
  "properties": {
    "attributes": [
      "attributes_itemsTitle",
      "attributes_itemsSubtitle"
    ],
    "collectionCode": [
      "Live"
    ],
    "dodiCode": "designs_projects"
  },
  "children": [
    {
      "type": "GreaterThan",
      "properties": {
        "inclusive": true
      },
      "children": [
        {
          "type": "Count",
          "properties": {
            "groupBy": "attributes_projectsTasks"
          }
        },
        {
          "type": "Attribute",
          "properties": {
            "attributeCode": "attributes_projectsCapacity_60464441c14e5d000ad7e479"
          }
        }
      ]
    }
  ]
}

Prior to this change, users could only compare a count node against a static Number node.

Expected Release Date

June 24th 2021

Overview

We have added a new Interface designInterfaces_itemsMetadata to Alloy Core Blueprints. This interface has four attributes, which allow you to see the username of the user who created or last edited an item, as well as create/last edit date and time.

Who will be affected?

All existing customers will be upgraded to gain access to this new interface. As this interface is part of Alloy Core, all new customers will have access to this interface by default. 

Details

For users wishing to see metadata on your custom design items, the design will need to be updated to implement designInterfaces_itemsMetadata. 

Four new attributes added by this interface are:

• Created By: attributes_itemsMetadataCreatedBy the username of the user who created the item 
• Created Time: attributes_itemsMetadataCreatedTime the item created date and time 
• Last Edit By: attributes_itemsMetadataLastEditBy the username of the user who edited this item last 
• Last Edit Time: attributes_itemsMetadataLastEditTime the item last edit date and time 

All of the above attributes are computed automatically by the Alloy Engine on item creation and each item edit. They will then be available to view listed alongside other existing item attributes on the design. 

Use Case

Once this interface is added to a design, the new attributes could be used within the templates for title/subtitle as usual. For example, if users want to quickly see who created a job they are working on, they could edit their job design title to something like

JOB-{{attributes_jobsJobNumber}}:{{attributes_itemsMetadataCreatedBy}}

This would then appear on each item title as JOB-123:johnsmith where johnsmith is the username of the user who created that job.

Expected Release Date

June 24th 2021