Layers can be used to display sets of data items on the map.

When you enable a layer, an initial query is performed to fetch the relevant data. The query is then repeated at regular intervals to keep the layer updated with any data changes. This is known as the build frequency.

The default build frequency is changing from 1 minute to 30 minutes.

Why? After some investigation, it became apparent that most layers don’t need to be updated so frequently. Therefore, this change will significantly lessen the impact on Alloy’s infrastructure, leading to performance gains elsewhere.

Who will be affected?

All customer projects containing layers that don’t have a custom build frequency set.

Details

After the release date, the Build frequency minutes property of all new and existing layers will be 30.

However, if an existing layer has a custom build frequency set, it won't be affected!

To set a custom build frequency for a layer in Alloy Web:

1. In the Layers panel, select the layer to view its details.
2. Switch to the General tab.
3. Select Edit in the bottom action bar, enter a new value, and then select Save.

API users can supply a value for the buildFrequencyMinutes property when using the Layer endpoint to create or edit a layer (see ReDoc).

Expected release

April 2024 after the Alloy v2.57 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

In the Report Builder, you can create an Item data source to represent the attributes and properties of a particular item, and an AQS data source to fetch the attribute data of multiple items.

You may have tried to use an Item data source as a parameter within an AQS data source, e.g. to fetch the defect items raised against that item. Currently, this doesn’t work because the Item Id header of the Item data source is a Text type, which isn't directly comparable with actual Item IDs.

Therefore, we're changing the Item Id header type from Text (string) to Link (AlloyId[]) to make this possible!

To accommodate this, a few other changes will also happen.

Who will be affected?

This will affect report builders wishing to use an Item data source as a parameter within an AQS data source.

Details

The Item data sources in everyone's custom reports will be updated with this change automatically.

However, any existing AQS data sources containing an unusable parameter as described above will still throw an error (1586360664 - Parameter type String cannot be used in node of type AlloyId). To fix this, simply recreate the parameter.

No more sorting by Item Id

After this change, it will no longer be possible to sort by the Item Id header on any data source. Doing so will throw an error (1603203353 - Ordering is not supported on the following type AlloyId).

Hardly anyone has attempted this, so we don't envisage it causing issues going forward.

More flexible joins

To create a Join data source, you must select a header from each of the two data sources you wish to join. Currently, you can only join headers of the same type (or a Link type to a Text type).

After this change, it will be possible to join a Text header to any other header type and vice versa. The other header type will be "stringified" for comparison.

AQS statistics constraints

AQS statistics data sources contain two headers to represent the data returned by its query. The Key header is a Text type and the Value header is a Number type.

After this change, API users will be able to specify the type of these headers via two new optional properties:

• KeyConstraint - corresponds to the attribute being grouped on, so can be set to any attribute type.
  
  
• ValueConstraint - corresponds to the aggregated values of the attribute being queried, so can be set to Number, DateTime or GeoJSON.

These can be declared within the relevant request model when using the /api/custom-report/{customReportCode}/data-source endpoint to add (Swagger/ReDoc) or edit (Swagger/ReDoc) an AQS statistics data source.

This will be useful for creating joins in some scenarios.

For example, imagine having an AQS statistics data source that counts Waste Containers grouped by type, and an AQS data source that fetches items of the Waste Container Types design.

To create a Join data source from these, you would select the Key header (String) of the first data source and the Item Id header (Link) of the second data source.

By default, the Item Id header will be stringified for comparison with the Key header, so the join should work. However, you can set KeyConstraint to "Link" to ensure an accurate comparison.

Expected release

29th June 2023 as part of the Alloy v2.48 release.

Overview

For those of you using Alloy to interact with the government's Street Manager service, an important transition is coming up.

In May 2022, the Department of Transport released v4.0 of the Street Manager API. Since then, they've continued to maintain endpoints for both v3 and v4.

While v3 isn't being decommissioned until May/June 2023, the legislative changes in v4 will come into force on 1st April 2023, effectively compelling all users to make the switch.

Therefore, we're updating Alloy to support the current v4.15 specification ahead of this deadline.

Who will be affected

This change will affect anyone using Alloy Web or Alloy Mobile to interact with the Street Manager service.

Details

Fortunately, there are only a few changes to learn about!

New permit conditions

• NCT09d - Changes to traffic management arrangements APPLIES TO ALL MAJOR PERMITS on Category 0, 1, and 2 streets only.
• NCT03 – Activities ancillary to those permitted – supplementary information.

For more detail, see the Statutory guidance for highway authorities.

New Traffic Management type

A new TM Carriageway Restriction Type will be available: Temporary obstruction 15 minute delay.

Footpath Closure

A new Foothpath Closure attribute will be mandatory for all permit requests.

Emergency Contact Name and Number

New Emergency Contact Name and Emergency Contact Number attributes will be optional for most permit requests, unless the chosen Traffic Management type is Multi Way Signals or Two Way Signals.

Expected Release

30th March 2023 as part of the Alloy v2.45 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.

Overview

When using the top-right Search panel to find items of a particular design or interface, you can customise how item attributes are searched, the collection(s) to be searched, and how the results are ordered.

However, these search settings currently apply to all designs/interfaces. This isn’t ideal, as what may be optimal for some designs/interfaces may not be optimal for others!

Therefore, as part of our continual efforts to add flexibility and improve consistency within Alloy, we’re making two important changes in this area:

• Search settings will be saved per design/interface.
  
  
• Search settings will affect item pickers as well as the Search panel.

Who will be affected?

These are broad changes that will affect most Alloy users.

Details

As before, when using the Search panel, you can customise your search settings like so:

• Select the search box, enter the name of a design/interface and press Enter.
  
  
• In the bottom action bar, select the More icon and choose Search settings.

However, when saving these settings, they will no longer be applied to all designs/interfaces. Instead, they will only be applied to the design/interface that you’re searching in.

This means you can save different search settings for different designs/interfaces, leading to a more efficient searching experience overall.

Item pickers

Search settings will be shared between the Search panel and item pickers, so saving custom settings for a design/interface in one will affect the other.

For example, imagine you’re creating a defect. In Step 2 of the procedure, you’re prompted to select the asset(s) you want to create a defect against. An item picker appears showing items of the Defects Assignable interface.

The items listed by the picker are subject to the same search settings as the Search panel. To access those settings, you can select the new cog icon (outlined in red above).

The orange dot over the icon indicates that custom settings have already been set for the design/interface being searched, which will affect the appearance and order of items shown in the picker.

Expected Release Date

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

Overview

This is a follow-up to a recent post about an issue affecting the import of geometry data in Alloy Web.

The issue was caused by a third-party service (espg.io), which provided Alloy with a list of Coordinate Reference Systems (CRS) and the corresponding proj4 strings required for converting the incoming geometry data accordingly. Upon discovering the issue, we quickly issued a temporary workaround.

To avoid this situation repeating in future, we’ve now removed this dependence from Alloy in favour of a curated local list.

Who will be affected?

This change affects all users who use Gateway to import geometry data in Alloy Web.

Details

When configuring an import in Alloy, there are two optional steps in the procedure that involve imported geometry:

• Attributes – in this step, you can map headers in the incoming data to attributes on the selected design. After selecting a GeoJSON attribute, you can select the Coordinate System field and choose one from the list (see below).
  
  
• Geometry – in this step, you can specify the type of geometry data to be imported. After selecting a Type, you can select the 🔍 icon in the Coordinate System field and choose one from the list (see below). Unlike the previous step, the full proj4 string will appear in the field, so it can be edited if necessary before selecting Done.

The coordinate system will default to WGS84 Lat/Lng if not explicitly set.

If you have any existing imports that include geometry data and have a Status of Configured or Validated, we recommend reconfiguring them. To do this, open the import item, select More in the bottom action bar and choose Reconfigure.

Available Coordinate Systems

We’ve included the most popular coordinate systems to choose from. Any others we should add? Please feel free to contact Support with your suggestions!💡

OSGB36 / British National Grid
SRID:27700
+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000 +y_0=-100000 +ellps=airy +towgs84=446.448,-125.157,542.06,0.15,0.247,0.842,-20.489 +units=m +no_defs

WGS84 Metres
SRID:3857
+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext  +no_defs

WGS84 Lat/Lng
SRID:4326
+proj=longlat +datum=WGS84 +no_defs

NZGD2000 / New Zealand Transverse Mercator
SRID:2193
+proj=tmerc +lat_0=0 +lon_0=173 +k=0.9996 +x_0=1600000 +y_0=10000000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs

Expected Release

Due to this new feature’s importance, it was hotfixed into the current Alloy v2.40 release on 17th October 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.

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