This month, we've concentrated on bug fixes and behind-the-scenes enhancements, though there are some new features to mention! The update took place during the evening of the 26th October. For a full list of changes in v2.52, please visit the Alloy Changelog.

Remove parent links on Mobile ❌🔗

When viewing an item's details in Alloy Mobile, the Originates From section lists any parent items that link to it. For instance, when viewing a defect, you can see the asset it applies to.

Sometimes, an item gets linked to the wrong parent. This can happen due to changing circumstances, insufficient data, or good old human error. If left unremedied, the problem can multiply.

For example, imagine an inspection scheduled for a street, based on a report by a member of the public. When the inspector arrives, they discover the defects are on an adjacent street. The completed inspection raises two defects, which in turn spawn two jobs, all of which point to the wrong street.

Therefore, you can now remove a parent link from an item in Alloy Mobile, while out in the field. Simply select the 3-dot icon beside Originates From and choose Remove. On Android, you can alternatively swipe the parent item to the left.

The ability to add a parent link is also coming to Alloy Mobile, so keep an eye out for future announcements 👀

Resume map position on Android 🗺️

Previously, after editing an item in Alloy Mobile Android, the map would reset to the default zoom level. While this behaviour was sometimes useful, it was counterproductive if you wanted to edit multiple items close together.

Now, the map remembers its last position, enabling you to resume from where you left off.

New API features 👩‍💻

Sometimes, new features are initially available only on the Alloy API. This lets us add new functionality more quickly, without having to make any user interface changes. In general, we seek to introduce the same features in Alloy Web, once we determine the best way of integrating them into Alloy Web's user interface.

This month, we've added three notable features to the API:

• In a workflow computation, you can now compute a time offset from a specific value (rather than the workflow's start time). In your WorkflowSyntaxNodeRelativeTimeWebModel, set offsetOrigin to Specified and supply an itemValue model. To learn more, see ReDoc.
  
  
• You can now include an entire manual workflow within another workflow! Simplify your workflows and reduce redundancy by creating distinct, reusable action sequences that can be referenced in other workflows. To learn more, see Goodbye Workflow Action Groups 👋. Coming soon to Alloy Web!
  
  
• When importing or exporting geometry data, you can now apply a custom transformation by specifying an uploaded grid shift file. To learn more, see Custom Grid Transformation 🌐.

By default, Alloy uses a simple Helmert transformation when converting geometry from the British National Grid coordinate system (EPSG:27700) to WGS 84 (EPSG:4326). This works well most of the time and requires no user input.

However, it can result in slight misalignment in a handful of cases, and we do like to give you choices where we can!

Therefore, as of the October 2023 update, you can now specify a grid shift file for a particular transformation (e.g. OSTN02, OSTN15) when importing or exporting geometry data via the API.

To use a different transformation, first upload its grid shift file to Alloy. The max size is 100MB and the supported formats are:  GSB, LLA, DAT.

Using the API

When using the Alloy API to import or export data, just add +nadgrids=<fileid> to the proj4 string (where <fileid>is the Item ID of your uploaded grid shift file).

When importing data using the ImportSettingsDataWebModel, you can specify the proj4 string as part of its geometry property.

When importing NSG/NLPG data using one of the two ImportSettingsStandardFormatWebModels, no proj4j string is specified. Instead, you can populate its gridFileItemID property with the Item ID of the grid shift file.

Using Alloy Web

When configuring a custom import in Alloy Web, you can configure the Geometry in step 3.

After choosing the Type, select the magnifier icon in the Coordinate system field and choose one of those listed. This populates the field with a proj4 string, which you can then suffix with +nadgrids=<fileid>.

Access policies are back, baby! Use them to enforce item-level access control.

Back in February, we announced that access policies were being temporarily removed, with a new implementation coming in future. They originally worked by tracing paths between the user and the item they were trying to access. In practice, the performance cost was too high, so we took them back to the drawing board.

We're pleased to announce that the new implementation of access policies has now arrived!

How do they work?

You can create one or more access policies for a particular design/interface. Each access policy can have one or more rules.

A rule applies to one or more user groups. It grants them conditional read access to items of that design/interface, based on the value each item has for a given attribute/property.

Currently, access policies can only be created and managed via the Alloy API.

What are they good for?

Access policies are enforced throughout Alloy. If a user isn't granted access to an item, it won't appear for them, regardless of whether they're using the map, the Data Explorer, etc.

This lets you control which items appear for which user groups. For example:

• The "Emergency" group can only see tasks whose Priority attribute is "High" or "Critical".
• The "Waste Sector C" group can only see waste jobs whose Geometry attribute is located within a specific area.
• The "Acme Contractor" group can only see assets whose Default Team attribute is set to one of their teams.

What about Permissions?

Access policies are designed to work alongside Permissions. Think of them as a more granular replacement for the Read permission.

If you enable the Read permission on a design/interface, it grants read access to all of its items.

Alternatively, you can disable the Read permission and use access policies to grant conditional access to items, based on the values they hold.

Learn more

To learn about creating and managing access policies via the Alloy API, see Access Policies on the Alloy Help site.

Please note: the relational expressions will become available on 30th November, as part of the Alloy v2.53 release.

We are absolutely thrilled to announce that Causeway Alloy has been shortlisted for the 'Asset Management Product of the Year' at this year's Construction Computing 'Hammers Awards'! 🎉

This recognition is a testament to our commitment to providing exceptional products for our customers. We take great pride in our innovative Asset Management solution and its ability to transform businesses.

Now, we need your support! Cast your vote for Causeway Alloy by clicking here: Vote!

Voting closes on Nov 1st with the winners announced on Nov 9th. Your vote will play a crucial role in determining the winner of this prestigious award.

We greatly appreciate your continued support and trust in our products. Thank you for being a part of our journey!

Overview

In the Report Builder, you can add a Repeater control to a flow document's layout that iterates over a specific header of a given data source. When the report is run, any "child" controls inside the Repeater control will appear once for each iteration.

Currently, the child controls within a Repeater control are automatically arranged in a vertical formation. However, depending on the data being repeated, this can lead to unnecessarily long documents containing lots of pages.

Therefore, we're making it possible to stack repeated content horizontally - by placing the Repeater control within a Horizontal stack control!

Who will be affected?

This will affect new and existing reports containing Repeater controls.

Details

Repeater controls at the root of a flow document will be unchanged.

However, if a Repeater control is placed within a container, the appearance of its child controls will be determined by that container. This means that:

• A Repeater control within a Horizontal stack control will now repeat horizontally.
• A Repeater control within a Vertical stack control will continue to repeat vertically.
• A Repeater control within a Repeater control will behave according to its parent control.
• The Repeater control's Margins and Relative Width won't be applicable.

Initially, repeated content will only appear horizontally when the report is run. The Document Layout Editor will be updated to reflect this new behaviour in the subsequent Alloy release.

Wrap child controls

As flow documents typically use portrait orientation, it's important for Horizontal stack controls to have their Wrap child controls property set to Yes when appropriate. Otherwise, their child controls may go off the page!

Therefore, to ensure that any newly-horizontal content remains visible after the change, we recommend checking your custom reports for any Repeater controls within Horizontal stack controls and configuring them as above.

Expected release

29th June 2023 as part of the Alloy v2.48 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.

We're pleased to announce that Alloy Help has received a beautiful makeover this week 💄.

The website has been rebuilt from the ground up to be bigger, bolder and easier to navigate.

Content now appears larger and fills more of the screen, making it clearer and more comfortable to read. The left sidebar can group articles more effectively for better browsing. A handy Table of Contents appears on the right, which displays an outline of the current article and your position in it, and lets you jump to a particular heading.

There's even a Dark Mode for some gentle night-time viewing 🌙.

This forms part of ongoing work to improve the quality and readability of Alloy's documentation, so you can find and absorb information when you need it.

To check it out, visit help.alloyapp.io or select the bottom-right ? icon in Alloy.

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.

As we reach the end of the year, it's time to look back at what we've all accomplished together in 2022. Liz and Kwarti, you can sit this one out... 😬

You loved it last year, so here it is again! We've put together a fancy webpage that you can log into to see all kinds of stats about your year in Alloy, delicately interwoven with the eccentric humour you've come to expect from us 😅

So go on, visit review2022.alloyapp.io and marvel at how busy your organisation has been this year. Feel free to share the URL of your personalised report with someone you want to impress, such as your boss or a prospective dating partner. Here's what Matthew McConaughey had to say about ours:

On behalf of the Alloy team, thanks for being with us in 2022, and we look forward to making 2023 even better 🎉

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.