Overview

When a staff member leaves an organisation, it’s common practice to disable any IT accounts used by them during their tenure. Currently, disabling an Alloy account requires you to contact our Support team.

However, it will soon be possible for Alloy Admins to disable/enable any account in their organisation!

After a user account has been disabled, the user’s name will remain visible throughout Alloy (e.g. in user lists, in team member lists). However, that user won’t be able to sign into Alloy Web or Alloy Mobile, nor will they be able to start a new session via the API.

Who will be affected?

These changes will affect System Admins who use the Web API to manage their organisation’s user accounts.

Details

A new User endpoint is being added to the Web API:

PUT api/user/{username} with request model CustomerUserEditWebRequestModel

If the enabled property is declared as false, the specified user’s account will become disabled.

The new endpoint’s documentation will be available on Swagger and ReDoc after release.

Expected Release Date

8th December 2022 as part of the Alloy v2.42 release.

Overview

As part of work to remove limitations to the number of items allowed in operations on the Extended API (https://extended.api.uk.alloyapp.io), the logic performed when creating/updating/deleting jobs will be moved to the Web API (https://api.uk.alloyapp.io).

This work is part of ongoing changes being made to functionality that has historically been available through the Extended API. Similar changes were made to defect logic (August) and inspection logic (September).

Who will be affected?

This change will affect any users who work with jobs in Alloy, as these changes will be introduced on the API used by both the web client and mobile apps.

Details

There have always been two routes to working with jobs:

• Through the Web API, where jobs are treated like any other item.
• Through the Extended API, where certain job-specific logic is applied when performing the same operations (e.g. limiting the number of asset parents a job can have).

However, the way in which this additional logic was applied in the Extended API required a limit on the number of items being operated on, to guard against service degradation. Therefore, we're moving this logic to the Web API, so these limits can be removed in future.

As a result, there will be some changes to the behaviour of the Web API Item endpoints when a job item is operated on.

Application of Special Parent Logic

When creating or editing a job via the Web API, if no geometry is supplied, geometry from the job's parent asset will be copied to the job.

However, this won’t happen if the parent asset is through a path more than two hops away (e.g. a job raised against a defect that’s already linked to the asset). In such cases, the geometry from a parent non-asset item will be copied instead.

Required Geometry from Parent Items will not be copied

If Geometry is required by the job's design, then specific geometry must be supplied to the Web API during any operation.

Previously, the Extended API would automatically copy geometry from the job’s parent item. This won’t happen when using the Web API.

Therefore, if you do want the job’s geometry to be copied from the parent (asset or activity), we recommend leaving Geometry as optional (as per the Tasks interface).

Removing Job Geometry will force a re-fetch from the Special Parent

When editing a job, removing its geometry will cause the Web API to copy the geometry from its parent item again.

This means it's effectively impossible to set a job's geometry to null if it has parents with geometry.

Extended Logic will appear as another entry in Item Audit Logs

Previously, any extended logic performed on a job item would be included in a single edit record in the item’s audit log.

Following this change, extended logic operations will be logged as a separate audit record to the main operation that triggered the change.

Changed Error Codes

Since this is effectively new logic being introduced, any errors encountered will generate different Alloy error numbers than the same error before the changes. This may affect error handling in any existing integrations.

Jobs can only have One Asset Parent Enforced

Previously, jobs created through the Extended API were only permitted to have one asset parent. Contravening this constraint would result in a server error (500) being thrown.

This has now been changed to return a bad user request (400) with the detail being ItemParentsContraintViolated instead of InternalError or DodiConstraint.

It was also possible to create jobs with multiple asset parents by creating them through the Web API instead of the Extended API. This will no longer be possible, as the same constraint will apply to the Web API Items endpoints.

No Automatic Raised Time

If no time is supplied for attributes_tasksRaisedTime when creating a job, the Extended API will automatically set it to the current date/time.

This functionality is planned for the Web API but isn’t available yet.

No Automatic Team Assignment 

If no team is supplied when creating a job, the Extended API will copy the default team from the parent asset (if set).

This functionality is planned for the Web API but isn’t available yet.

Expected Release Date

27th October 2022 as part of the Alloy v2.41 release

It's been over two years since our new alloyapp.io domain became the default for Alloy users. Since then, we've been redirecting from the old alloy.yotta.co.uk  and alloy.yotta.net.au domains to uk.alloyapp.io and au.alloyapp.io respectively.

Traffic monitoring shows us that there's been very little activity on these for a while now, which means you're all using the new URLs! Therefore, the redirects will be retired on 16th October 2022.

This change shouldn't affect any Alloy users, but if you have any of the old URLs saved as a bookmark or in a document somewhere, please update them!

We'd like to take this opportunity to say a big thank you from everyone on the Alloy team for continuing to join us on this journey 👍🏼

Overview

When using workflows to process large numbers of items, performance can start to become a limiting factor. To give you more control over how workflows are performed, you can now choose whether workflows operate in Single Item or Multiple Item mode.

Typically, a workflow that outputs a single item is easier to work with. However, when there are thousands of items to process, running thousands of corresponding workflows can get a bit slow!

In such situations, processing multiple items in a single workflow provides a huge performance boost, which is typically worth the price of having the workflow output all the items at once.

The current behaviour is as follows:

• Event workflows – a workflow is performed for each item.
  
  
• Manual workflows – a single workflow performs on all items passed to it (10,000 items max).

The upcoming changes essentially give you the option of swapping these behaviours if desired.

Who will be affected?

The changes will affect any users that create and edit workflows via the Alloy API. The new properties described below will eventually surface in Alloy Web.

Details

Event workflows

A new optional property outputMode will be added to the EventTrigger on the Workflow Create (ReDoc) and Workflow Edit (ReDoc) endpoints. The default value is OneItem.

When set to ManyItems, the event workflow will run with as many items as possible on its trigger node (depending on the item collection/event type). The performance will be orders of magnitude faster then processing the equivalent workload in OneItem mode.

Expected Release Date – 29th September 2022 as part of the Alloy v2.40 release.

Manual workflows

A new optional property WorkflowManualTriggerOutputMode will be added to the ManualTrigger on the Workflow Create (ReDoc) and Workflow Edit (ReDoc) endpoints. The default value is ManyItems.

When set to OneItem, the manual workflow will run once for each item passed to it. For example, if a workflow creates an invoice when supplied with an account's Item Id, the workflow will run once for each account, thereby generating an invoice for each one. It wouldn't be possible to do this in ManyItem mode.

Expected Release Date – 27th October 2022 as part of the Alloy v2.41 release.

Note: Due to a technical issue, this change was made to the Web API before the announcement was made. We wish to apologise for any inconvenience this has caused.

Overview

As part of work to remove limitations to the number of items allowed in operations on the Extended API (https://extended.api.uk.alloyapp.io/), the logic that's applied to inspection creation/updating/deletion will be moved to the Web API (https://api.uk.alloyapp.io/). This work is part of ongoing changes being made to functionality that has historically been available through the Extended API. This work is similar to the changes made to the defect logic in August (Defect Logic Announcement).

Who will be affected?

This change will affect any users who work with inspections in Alloy, as these changes will be introduced on the API used by both the web client and mobile apps.

Details

There have always been two routes to work with inspections:

1. through the Web API, where inspections are treated like any other item
2. through the Extended API, where certain inspection-specific logic is applied when carrying out the same operations. For example, limiting the number of asset parents an inspection can have, and applying relevant date values such as Raised Time.

However, the way in which this additional logic was applied in the Extended API required a limit on the number of items being operated on, to guard against service degradation. Therefore, we're moving this logic to the Web API, in order to remove these limits in the future.

As a result, there will be a few changes to the behaviour of the Web API Item endpoints when an inspection item is operated on in the following ways.

Application of Special Parent Logic

When creating or editing an inspection, geometry from the inspection's parent asset will typically be copied to the inspection if no geometry is supplied.

However, this will not happen if the parent asset is through a path more than two hops away (such as an inspection raised against a defect that is already linked to the asset). In these cases, the geometry from a parent non-asset item will be copied.

Required Geometry from Parent Items will not be copied

If Geometry is required on the inspection design, then specific geometry must be supplied to the API during any operation.

Previously, the Extended API would automatically copy geometry from the parent item for the inspection. This will not happen when using the Web API.

For activities where you would like the geometry to be automatically set to that of the parent (asset or activity), we recommend that Geometry is left optional (as per the Tasks interface).

Removing Inspection Geometry will force a re-fetch from the Special Parent

When editing an inspection, removing its geometry will cause the Web API to re-fetch the parent item's geometry and set the inspection's geometry to that. This means it's effectively impossible to set an inspection's geometry to null if it has parents with geometry.

Extended Logic will appear as another entry in Item Audit Logs

Previously, extended logic applied to inspection items would be included in a single edit record in the item audit. Following this change, extended logic operations will be added as a separate audit record to the main operation that triggered the change.

Changed Error Codes

Since this is effectively new logic being introduced, any errors encountered will generate different Alloy error numbers than the same error before the changes. This may affect error handling in any existing integrations.

Inspections can only have One Asset Parent Enforced

Previously, inspections created through the Extended API were only permitted to have one asset parent. Contravening this constraint would result in a server error (500) being thrown.

This has now been changed to return a bad user request (400) with detail being ItemParentsContraintViolated instead of InternalError.

Also, it was previously possible to create inspections with multiple asset parents by creating them through the Web API. This is now no longer possible, as the same constraint will now apply to the Web API Items endpoints.

No Automatic Raised Time

If no time is supplied for attributes_tasksRaisedTime when creating a job, the Extended API will automatically set it to the current date/time.

This functionality is planned for the Web API but isn’t available yet.

No Automatic Team Assignment 

If no team is supplied when creating a job, the Extended API will copy the default team from the parent asset (if set).

This functionality is planned for the Web API but isn’t available yet.

Expected Release Date

1st September 2022

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

As part of work to remove limitations to the number of items allowed in operations on the Extended API (https://extended.api.uk.alloyapp.io/), logic applied to defect creation, updating and deletion will now be added to the Web API (https://api.uk.alloyapp.io/). This is the first of many changes we will be making to functionality currently available via the Extended API over the coming months.

Who will be affected?

This change will affect any users who work with defects in Alloy as these changes will be introduced on the API used by both the web client and mobile apps.

Details

There have always been two routes to work with defects, either through the Web API, where defects are treated the same as any other item or through the recommended Extended API where certain logic, specific to defects, is applied when carrying out the same operations. The way in which this additional logic was applied in the Extended API  meant that limits to the number of items operated on needed to be put in place to guard against service degradation. Moving this logic down to the Web API is required to remove these limits in the future.

These changes will result in a few changes in behaviour of the Web API Item endpoints when a defect item is operated on in the below ways:

Application of Special Parent Logic

When creating or editing a defect, geometry from the defect's parent asset will be copied to the defect if no geometry is supplied in most situations. This will not be the case if the parent asset is through a path that is more than two hops away (such as a defect raised against an inspection that is already linked to the asset), in these cases, the geometry from a parent non-asset item will be copied.

Required Geometry from Parent Items will not be copied

If Geometry is required on the defect design, then specific geometry must be supplied to the API during any operation. Previously, the Extended API would automatically copy geometry from the parent item for the defect, this will not happen when using the Web API. We therefore recommend that for activities where you would like the geometry to be automatically set to that of the parent (asset or activity), that the Geometry be left as optional as per the defects interface.

Removing Defect Geometry will force Re-fetch from the Special Parent

When editing a defect, removing the defect's geometry will cause the Web API to re-fetch the parent item's geometry and set the defect's geometry to that. This means it is effectively not possible to set a defect's geometry to null if it has parents with geometry set.

Extended Logic will appear as another entry in Item Audit Logs

Previously, extended logic applied to defect items would be included in a single edit record in the item audit. Following this change, extended logic operations will be added as a separate audit record to the main operation that triggered the change.

Changed Error Codes

Since this is effectively new logic being introduced, any errors encountered will generate different Alloy error numbers than the same error before the changes. This may affect any error handling in any existing integrations.

Defects can only have One Asset Parent Enforced

Previously, defects created through the Extended API were only permitted to have one asset parent. Contravening this constraint would result in a server error (500) being thrown. This has now been changed to return a bad user request (400) with detail being ItemParentsContraintViolated instead of InternalError.

Also, previously it was possible to create defects with multiple asset parents by creating them through the Web API, this is now no longer possible as the constraint will now apply to the Web API Items endpoints.

Defect Raised Time

The most visible change will be when creating defects through the Web API, if no time is supplied for attributes_defectsRaisedTime this will be automatically populated to the current date/time.

Expected Release Date

25th August 2022

Overview

It's now possible for an item to display different Titles/Subtitles depending on which collection it belongs to. This is primarily intended to help you differentiate between template items and live items.

Who will be affected?

This change will affect:

• users who create designs
• users who create template items

Details

A template item usually contains a custom Title/Subtitle, often including variables that will be populated when a live item is created from that template. While this powerful customisation is useful, it can make distinguishing between templates and live items tricky!

Therefore, you can now specify multiple Title/Subtitle values in a design, and items will use the appropriate Title/Subtitle for the collection they're in.

This enables you to label your template items effectively, while ensuring live items created from those templates will use the intended Title/Subtitle. You could also do this for archived items.

To do this, use #if and #else conditions in your Mustache templates that reference specific collections. For example:

{{#if collection_live}}Live Item Title{{#else}}Some Other Title{{/if}}

You can also use #elif ("else if") to add more conditions. For example:

{{#if collection_template}}Template Title
{{#elif collection_archive}}Archived Title
{{#else}}{{attributes_streetLightingUnitsUnitNumber}}
{{/if}}

Expected Release Date

29th July 2022 as part of the Alloy v2.39 release

Overview

A new setting can be added to workspaces to determine how long audit logs should be retained. Any logs older than the number of days specified will be deleted. This does not affect backups. This is to allow for greater control over the amount of storage space being used within workspaces.

Who will be affected?

This change will primarily affect users who interrogate the audit logs and system administrators.

Details

Audit logs are now automatically removed by the Alloy engine depending on a retention policy setting applied to workspaces. This policy defines the number of days audit logs should be retained for. If this setting is not present, audit logs are not removed. This setting is being made available to allow for greater control over the amount of storage space a workspace uses on the Alloy server. Where a retention policy is not configured, the audit logs will be held indefinitely.

Currently, this setting can only be set by the support team. Please contact the support team if you wish to enable this setting.

Expected Release Date

30th June 2022 as part of the Alloy v2.37 release

If you have ever wanted to connect with other Alloy users, we have recently set up a great place to do just that! Alloy Community is a place for users to discuss how they're using Alloy, ask for help, get support with issues and to discover more information about Alloy's uses. Anyone can sign up to post and it is routinely contributed to by a lot of the people involved in building Alloy.

If you haven't had a look yet, why not check it out?

Alloy Community