Items now have the Context property

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

Change to AQS Query Results Display in Custom Reports

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.

Given the specific nature of this change, we do not expect it to widely affect users. However, if you notice that this change has had an adverse affect on the output in your reports, please do contact our support team.

 

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


Passwords to Require at Least One Special Character

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

Alloy API now OpenAPI 3.0 Compliant

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

API Rate Limiting Responses

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

Item Level Count Is Now Supported by AQS Expressions

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

Mesh Open API Support and Deprecations

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

Removal of DoDI Obsolete Properties

Overview

As previously announced in Design Properties to Be Supported on Design Interfaces published on 03/08/2020, we are now implementing Phase 2 where obsolete properties are to be removed.

Please note that there will be a final Phase 3 to remove service code that exists to support backward compatibility, as described below.

Who will this affect?

This change will affect all integrations that have not been updated in line with the previously announced changes. Any integration relying on obsolete properties may cease to function.  

Details

Both Design and DesignInterface Web Models will no longer return title and subtitle string properties, rather just their DoDI equivalents dodiTitle and  dodiSubtitle with parent information. Similarly DesignWebModel will no longer return old properties named colour, icon, versioned, geometry and collections and their DoDI counterparts should be used instead.  

Following this change, the Design response will look as follows:

{
    "design": {
        "name": "Design Name",
        "code": "designs_designName_600aceb294eba00ddc382a9e",
        "context": "Customer",
        "implements": [{
                "code": "designInterfaces_items",
                "parent": "designs_designName_600aceb294eba00ddc382a9e"
            }, {
                "code": "designInterfaces_interfaceForImplements",
                "parent": "designs_designName_600aceb294eba00ddc382a9e"
            }
        ],
        "attributes": [...],
        "metadata": {...},
        "dodiTitle": {
            "value": "Design Title",
            "parent": "designs_designName_600aceb294eba00ddc382a9e"
        },
        "dodiSubtitle": {
            "value": "Interface Subtitle",
            "parent": "designInterfaces_interfaceForImplements"
        },
        "dodiColour": {
          "value": "#3d8fbd",
          "parent": "engine_defaultedProperties"
        },
        "dodiIcon": {
            "value": "icon-edited",
            "parent": "designs_designName_600aceb294eba00ddc382a9e"
        },
        "dodiVersioned": {
            "value": true,
            "parent": "designInterfaces_interfaceForImplements"
        },
        "geometryRequired": {
            "value": false,
            "parent": "engine_defaultedProperties"
        },
        "geometryAllows": {
            "values": [
                "Point",
                "LineString"
            ],
            "parent": "designs_designName_600aceb294eba00ddc382a9e"
        },
        "dodiCollections": {
            "values": [
                "Live",
                "Inventory",
                "Archive"
            ],
            "parent": "designs_designName_600aceb294eba00ddc382a9e"
        },
        "discriminator": "DesignWebModel"
    },
    "operationsSummary": {...}
}

DesignEditWebRequestModel 

Obsolete design geometry will be removed in favour ogeometryRequired and geometryAllows properties introduced during Phase 1.

Phase 3 changes

At the moment service code does not apply changes to the design if it detects that value passed in is same as old value that comes from inheritance chain (implements or defaults). For the above design example this means if the edit is called with new subtitle being "Interface Subtitle" or colour "#3d8fbd", no parent change would be applied and returned designs will still come back with the same parents.

"dodiSubtitle": {
    "value": "Interface Subtitle",
    "parent": "designInterfaces_interfaceForImplements"
},
"dodiColour": {
  "value": "#3d8fbd",
  "parent": "engine_defaultedProperties"
}

However, after Phase 3 we will remove extra checks in the service and any property set on DesignEditWebRequestModel will use the edited design code as it's parent i.e. the above edit will result in parent change on retuned DoDI properties.

"dodiSubtitle": {
    "value": "Interface Subtitle",
    "parent": "designs_designName_600aceb294eba00ddc382a9e"
},
"dodiColour": {
  "value": "#3d8fbd",
  "parent": "designs_designName_600aceb294eba00ddc382a9e"
}

After Phase 3 is implemented, it will be caller's responsibility to check parent properties and not send properties that they do not want to set directly on the edited design i.e. if above parent change was not intended DesignEditWebRequestModel would be called with NULL subtitle and colour, which would ensure that returned value is calculated from the inheritance chain or defaulted.

Phase 2 Expected Release Date

March 25th 2021 

Phase 3 Expected Release Date

August 26th 2021

File Upload and Download Forbid Certain Extensions

Overview

To improve security, we will be making changes to restrict the types of files that can be uploaded and downloaded via the API based on the extension.

Who will this affect?

This will affect anyone uploading files to or downloading files from Alloy that have extensions that could be deemed to be executables. 

Details

The Alloy API for file upload and download will restrict certain file extensions for security reasons. The list includes ".exe", ".bat", ".com" among others.

The list mirrors the extensions forbidden by Microsoft Outlook, see here for the full list of forbidden extensions.

Expected Release Date

February 25th 2021

Extended Web API changes for Financial Accounts

Overview

As part of the work for the new Financial Accounts module, we are making changes to Extended Web API endpoints and logic to support Job Bill Items and Supplier/Customer Accounts.

Who is affected?

Users of Extended Web API who are using Work Item and Job Work Item endpoints.

This change is planned to roll out in two phases. This phase introduces new Extended Web API endpoints and marks old as obsolete, while the second phase will remove them.

Details

All Work Item and Job Work Item endpoints are now marked as obsolete i.e. routes starting with api/work-item or api/job-work-item

Job Work Units

For create, read, update and delete (CRUD) operations on Job Work Units (Job Work Items or Job Bill Items) callers should start using new Job Work Unit endpoints, starting with the api/job-work-unit route.

Work Items

The old Work Item endpoints are split into two routes: Work Unit api/work-unit and Change Component Work Item api/change-component-work-item. The first endpoint deals with applicable Design and Design Interfaces (DoDIs) for all Work Units (Work Items and Bill Items), while the second one handles applicable component DoDIs specifically for Change Component Work Items (i.e. items belonging to designs_changeComponentWorkItems).

Job Edit

As part of this change, the job edit endpoint now also handles Job Bill Items cost re-calculation when the parent asset item is set, changed, unset or the job status is changed to Completed. Please note that it is important to use the Extended Web API job edit endpoint api/job/{id} to alter the relationship between job and it's parent asset item, otherwise the cost calculation for Job Work Units will not be applied.

Budget Summary

The Budget summary endpoint api/budget/{id}/summary now returns extra results for each of BudgetPeriodJobCostsWebModel with information about the BillsPerJobStatuses in addition to existing CostsPerJobStatuses. Costs are calculated as before using costs of all Job Work Items for jobs that fall into specific budget period, while Bills now used the same logic but are using costs of Job Bill Items on jobs in budget periods.

Team Pricing to Account Pricing

As part of Finance Module, Team Pricing will become Account Pricing with all teams linked to an account sharing the pricing structure. Users should move any pricing data linked to a Team via attributes_teamsPricingTeamPricing to a supplier account (designs_supplierAccounts) using the attributes_financialAccountsPricing link instead as we plan on removing the link from Teams to Team pricing in due course.

The Extended API will first check for rates using Account Pricing  attributes_financialAccountsPricing but will continue to support cost calculation via attributes_teamsPricingTeamPricing when no account pricing is available for the time being. 

Additionally, all work items will now temporarily have two pricing attributes, the previous attributes_workItemsTeamPricing and a new link via work units pricing interface attributes_workUnitPricingPricing. Again, the Extended API code will first check for rates using the Work Unit pricing before falling back to the previous Work Item link. The Work Item link will also be removed once users have had opportunity to migrate their data. 

Expected Release Date

October 29th 2020


Show Previous EntriesShow Previous Entries