Alloy January 2023 Update

We're starting the year off with a modest update. Nothing too crazy, just a few useful improvements to make your experience better 😊 (especially on Android). The update took place during the evening of the 26th January. For a full list of changes in v2.43, please visit the Alloy Changelog.

Extend Blueprinted Designs/Interfaces with Custom Interfaces

In September, we announced the introduction of custom interfaces. For the first time, it was possible to create a new interface that one or more designs could implement, providing a way to share a single set of generic attributes across multiple custom designs.

For technical reasons, it wasn't originally possible for a blueprinted design/interface to implement a custom interface. But not anymore!

Now, a custom interface can be implemented by any design/interface, regardless of whether its Context is Core, Module or Customer.

This fully unlocks the possibilities of custom interfaces, as they can now be used to extend the hundreds of ready-made designs/interfaces available in Alloy.

Bulk Invoice Workflows

For customers with the Financial Accounts module installed, this will be a welcome announcement!

A new module is available containing two manual workflows, which can automatically generate invoices for a list of Customer Accounts or Supplier Accounts.

For each account, the workflow will find all the related job work units that have their Invoicing status set to Ready and process them all into a single Account Invoice item for that account.

The resulting Account Invoices will be left with their Status set to Draft, giving you the opportunity to double-check everything and make any changes before progressing them to Issued.

We know that some of you need to process hundreds of invoices at a time, so these new workflows will save you a lot of time and effort! If you'd like the new module to be enabled for your Alloy customer project, please contact Support.

See Nearby Items when Editing Geometry on Alloy Mobile

Previously, when creating geometry for a new item (or editing the geometry of an existing item), the map area would appear empty.

Even with the Satellite basemap enabled, being unable to see the position and shape of nearby objects could sometimes make plotting the new geometry a bit tricky.

The items on your map now remain visible when editing geometry, making it easier to draw points or polygons accurately in relation to nearby items.

The items shown respect the layer configuration of the main map and the Search Here button can be used to refresh the current view.

Multiple Improvements on Android

Alloy Mobile has received special attention on Android this month, incorporating several changes that were recently implemented for iOS.

Item Forms on Android

If a custom item form exists for a design/interface, it will now be displayed to Android users when they create or edit a corresponding item. Users will only see the attributes that the item form has controls for, listed in the order defined by the item form.

Otherwise, the standard item form will be displayed. Users will see all the design/interface's attributes, listed in chronological order.

Prevent Locked Items Being Edited on Android

In Alloy Web, items can be locked to prevent them being edited. This can be done manually via the action bar or automatically via a workflow.

When locked items get synced to Alloy Mobile Android, they now display a visual indication of their locked status if you try to edit them. Users can no longer edit the locked item’s attributes or add/remove any items associated with it (e.g. attachments, job work items, related tasks).

Read-only View of Link Attributes on Android

When an item has a Link attribute that references multiple items (e.g. a job with multiple job work items), it shows as “X selected” when viewing the item's details in Alloy Mobile Android.

Tapping this now always displays the list of referenced items, even if the attribute is set to Read-only, or your user account has Read-only permission to the attribute.

What did you do in 2022? πŸ“…

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 🎉

Alloy December 2022 Update

This month’s update provides a number of useful improvements across the board. The update took place during the evening of the 8th December. For a full list of changes in v2.42, please visit the Alloy Changelog.

Design/Interface Search Settings 🔍

When using the top-right Search panel to find items of a particular design or interface, there are several settings you can change to customise how searching works and how the results are displayed.

Before, these search settings were applied across all designs/interfaces. Now, they are saved per design/interface. This lets you be selective with your search customisation, so you can apply different optimisations to the designs/interfaces that are important to you.

For example, if you prefer to see Tasks sorted by their Created Time, this can now be set without affecting other designs/interfaces.

Additionally, these search settings now apply to item pickers as well, providing you with a consistent experience whenever Alloy presents you with a list of items for that design/interface.

For more details, please see this previous announcement and the Alloy User Guide.

Note: the search settings currently don't affect how Work Items or Bill Items are displayed in the Job Work Unit Editor. We're working to address this in an upcoming release.

Item Forms - New File Picker Control 📎

If you want to attach a file to an item, you no longer need to upload the file to Alloy first!

When creating/editing an item, it's now possible to upload a new file as you're configuring its Attachments attribute.

This is made possible by the availability of a new File picker control in item forms. When editing an item form for a particular design/interface, you can choose to add a File picker control for the Attachments attribute (or any Link attribute that references Files items).

When the item form is presented to a user (i.e. they create or edit an item of the relevant design/interface), selecting the File picker control will display a browsable folder structure where they can select one or more files stored within Alloy.

However, the user can also use the highlighted button to upload a new file and select it for inclusion.

Bulk Download Attachments 🖇️⬇️

When viewing an item's details, if you switch to the Attachments tab, you can now select Download all from the action bar to download all the attached files in a single zip file.

A simple but useful improvement!

Disable Module Workflows

Another simple improvement is the ability to disable any of the system workflows that appeared in your Alloy customer project after a particular module was enabled.

For example, you want to disable the Invoice Calculation workflow included with the Financial Accounts and Invoicing module because your organisation uses a custom-designed workflow instead.

When viewing the details of a workflow included with a module, you can now select Edit in the action bar and change Enabled to false, so it no longer appears in the list of runnable workflows.

Manual Workflow Output Mode

When creating a manual workflow, there's now an optional Output mode field that determines how items will be processed when the workflow is run.

The possible values are:

  • Many items - all items are processed by a single workflow (used by default).

  • One item - each item is processed separately by its own workflow. Slower but makes certain operations possible, e.g. if a workflow creates an invoice when supplied with an account’s Item ID, it will run once for each account, thereby generating an invoice for each one.

Alloy Mobile - iOS 16 Support 📱

In line with our policy to support the latest three versions of iOS, Alloy Mobile is now supported on iOS 16!

This means that we've performed a series of exhaustive tests on all aspects of the app running on iOS 16 and completed any work required to ensure stable operation. On this occasion, we only had to correct a couple of minor issues encountered when adding attachments to an item (such as a "Cancel" button appearing white on a white background).

As we take on iOS 16, we therefore say goodbye to iOS 13 👋. While Alloy Mobile can still be used on devices running iOS 13, the app will only be tested on iOS 14-16 from this point onwards. Therefore, if you were to encounter an issue on iOS 13, only basic troubleshooting support would be available.

Fortunately, all iOS 13 devices can be upgraded to iOS 15, therefore we strongly recommend doing so to receive the best experience going forward.

Removal of Access Policies

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.

Removal of old API key mechanism πŸ”‘

Overview

Back in December 2021, we announced that the mechanism for API keys would be changing.

In summary, API keys would no longer be generated automatically for every user, so new API keys must be generated on demand. Additionally, these new API keys must be passed using the OAuth 2.0 Bearer token format. For full details, please see the previous New API Key Management announcement.

These changes were implemented on 13th January 2022, with the old API keys remaining valid for a year.

Therefore, this is to remind everyone that the old API key mechanism will be removed in January 2023!

Who will be affected?

Any user or integration that still uses an old API key to communicate with the Alloy APIs.

Details

As of the release date below, old API keys that were created before 13th January 2022 will no longer be valid.

Additionally, the /api/user/me endpoint (Swagger/ReDoc) will no longer include the old apiKey property in its responses.

To learn about the new endpoints for managing API keys, please see the previous New API Key Management announcement.

How can I check my API key?

The simplest way to check if your API key is "old" or "new" is to consult your code. Does it pass the API key in the OAuth 2.0 Bearer token format (RFC 6750)? If so, your API key is new!

Alternatively, you can use the GET /api/user/me endpoint (Swagger/ReDoc) before the release date to return information about the currently logged in user. If your API key matches the value of the depreciated apiKey property in the returned user, your API key is old.

If in doubt, we recommend using the POST /api/api-key endpoint (Swagger/ReDoc) to create a new API key.

Mesh Users

If you have any workflows that use a Call Mesh action, your Alloy customer project will need updating with a new API key. We've been reaching out to customers we believe to be affected by this, but if in doubt, please contact Support to request this.

Expected Release Date

26th January 2023 as part of the Alloy v2.43 release.

New Alloy safety limits πŸ›‘

Overview

This is to inform all users that we've recently implemented three safety limits to Alloy’s engine.

These have been put in place to help ensure that the performance, reliability and security of Alloy remains high. Rest assured, these limits have been calculated carefully, so most users will never reach them!

In rare cases where a limit is reached, users will receive a detailed error message to inform them what has happened, so the situation can be avoided in future.

Who will be affected?

These limits affect all users of Alloy but will be unnoticeable by most.

Details

The following limits have been added.

Maximum Background Tasks

The number of background tasks that can be queued per customer project. This has been limited to 100,000 tasks, which is far higher than has ever been reached before.

If the limit is reached, attempting to create a task will fail with this error:

Error Category: ResourceLimited,  Error Code: 1657552956

Maximum Item Size

The size of any item being operated on. This has been limited to 2MB (roughly 420,000 words of text) for optimal resource management.

If the limit is reached, the operation will fail with this error:

Error Category: ItemSizeExceedLimit, Error Code: 1657279454

Maximum Items to Query in Bulk

The total number of items involved with any write operations. While a query may only affect a moderate number of items directly, each item may have child/parent items that need querying too. Therefore, this has been limited to 200,000 items on the Task Executor (75,000 items on the API services).

If the limit is reached, the query will fail with this error:

Error Category: BulkQueryLimitExceeded

Alloy October 2022 Update

This month’s update provides item form improvements, the ability to attach files directly to permit applications, and a brand new map tool! The update took place during the evening of the 27th October. For a full list of changes in v2.41, please visit the Alloy Changelog.

New Measure Tool 📐

You asked for it, you’ve got it!

Alloy has a new Measure tool that can accurately measure the length between two points, the total length between multiple points, and the area of a closed shape.

It’s simple to use – just select the tool and then select two points on the map to draw a line between them. Continue selecting points to draw more lines. The length of each line is calculated and displayed in real-time, as is the total Length displayed in the bottom-left corner.

Double-select the last point to finish your initial drawing. If you do this over the first point, the Area of your closed shape will also be displayed.

You can then adjust your drawing by dragging any of its points, or adding new points along any of its lines.

This new tool will no doubt prove useful across many different service areas and reduces the need to visit sites, saving considerable time, costs and emissions.

Item Form Improvements

We’re continuing to improve the new item forms feature, which makes it possible to customise the form that users fill in when creating or editing items of a particular design/interface (introduced in the Alloy September 2022 Update).

New label property

All item form controls now have a Label property, which lets you set a display name for the control. If left blank, the attribute's name will be used.

New Multiline control

When adding a Text attribute to an item form, you can now choose a Multiline text input control. Unlike the standard Text input control, this new control can display multiple lines of text at once.

When a user selects the field on the form, a large text box will appear for them to write into.

New Super Globals

First, some background information!

We’re gradually improving support for expressions in item forms. An expression takes zero or more inputs, performs one or more logical operations, and produces one output. By utilising expressions, item forms can be context-sensitive and react to user input.

When configuring a control on an item form, you can target any of its properties to the output of a saved expression. This lets a property react to the status of other controls within the item form, e.g. make a read-only control writable if a Checkbox control is checked

Super globals are effectively system-wide variables that can be referenced in expressions. They make it possible for a property to react to the status of many other things in Alloy. For example:

  • details of the current user (e.g. name, username, email address, item ID)
  • details of the current item form (e.g. name, code, whether it’s operating in Create or Edit mode)
  • details of the item being created/edited (e.g. item ID, design name and code, collection, parent item ID)

For a full list, see the Alloy User Guide.

This opens up all sorts of possibilities!

For example, imagine your item form has an Item picker control that displays the lookup list for a Link attribute. Using the power of expressions and super globals, it could now be configured to only list items with the same parent as the item being created/edited by the form. We know this is something many of you have wanted for a while!

While expressions remain developer-focused for now, this is an important part of ongoing efforts to develop the feature. We plan to make expressions available to a wider audience when we release a user-friendly expression builder in the not-too-distant future.

Indicate Required Attributes *️

Previously, when creating/editing an item, Alloy displayed all of the required attributes and hid the others behind a Show Options button. With the introduction of item forms, this behaviour has had to change.

Therefore, Alloy now marks any required attribute with an orange asterisk. This happens automatically, regardless of whether an item form is created for a design/interface or not.

Attachments for Permit Applications📎

For Street Works users, applying for permits is a regular procedure. Permits often require supporting documents and photos. While permits can have file attachments, you could only add them after the permit was created. This was a bit of a hassle!

Therefore, we’ve now added an optional Attachments step to the permit application itself, so you no longer have to spend extra time attaching files afterwards.

New Rounds setting on Alloy Mobile Android

In response to customer feedback, we’ve added a new Go to rounds on login setting to Alloy Mobile on Android.

If enabled, the app will automatically show the Rounds panel after logging in. This happens immediately, so you don't need to wait for the automatic sync to finish (your Rounds will refresh afterwards).

This will be especially useful for vehicle-based users who seek to minimise time spent between tasks.


Changes to the ApplicableTypes endpoints

Overview

We recently added several Applicable Type endpoints to the Web API: https://announcements.alloyapp.io/applicable-types-now-enforced-by-web-api-3jpgbe

Applicable Types define how items of various activity-related designs can link to each other, e.g.

  • Which Asset types can each Job/Inspection/Defect type be linked to?
  • Which Job types can each Job Work Unit type be linked to?

When using the api/applicable-type/applicable-from endpoint, you may receive some unexpected results. Put simply, this is because the current logic is finding links that can be applicable but haven’t explicitly been made applicable.

To improve this, we’re changing how the endpoint behaves. Rather than accepting a list of designs, it will instead accept a list of items. The new logic will be able to use the parent or child items to determine which DoDIs or items are applicable from that item.

This should produce results that are more in line with expectations! However, it will require some breaking changes. 😐

Who will be affected?

These breaking changes will affect anyone who uses the ApplicableTypes endpoints on the Web API.

Details

New Endpoint Addresses

The addresses of the following endpoints will be changing.

List Applicable From Types endpoint

The request for this endpoint (ApplicableTypeFromWebRequestModel) will be changing:

  • The toAll property will be removed.
  • The from property will no longer accept a ApplicableFromItemWebModel (item IDs) and therefore will no longer require a discriminator. It will only accept ApplicableFromDodiWebModel (DoDi codes).
  • The toAllItems required property will be added (to replace toAll). This is an array of item IDs that you wish to check.
  • The filterAttributeCode required property will be added. This specifies the link attribute to find applicable types on. The attribute must be present on all the items provided in toAllItems.

For example, to query which job types can be raised against specific assets, you would provide these values for the aforementioned parameters:

  • ToAllItems = an array of asset item IDs
  • FilterAttributeCode = attributes_tasksAssignableTasks
  • From = designInterfaces_jobs
    (to exclude inspections and other task types)

Additionally, the response model for this endpoint (ApplicableTypeFromWebResponseModel) will also be changing:

  • The NoRestrictions property will be added.  If no results are returned, this boolean explains why. If true, there are no restrictions, which means everything applies. If false, it means that nothing applies.
  • The results can be of type ApplicableFromDodiWebResponseModel or ApplicableFromItemResultWebModel, so these are the new discriminators to use (no more ApplicableItemWebModel).

Importantly, this revised endpoint won’t support finding applicable job types for supplied work unit items. This will be handled by a new endpoint coming in future.

List Applicable To Types endpoint

The response for this endpoint will be changing:

  • The results can only be of type ApplicableToDodiWebResponseModel. Therefore, it will no longer be necessary to supply a discriminator.

Expected Release

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

The documentation available on Swagger and ReDoc will be updated accordingly.

New Coordinate System picker for Imported Geometry 🌐

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.

Job Work Unit Logic in Web API

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 and deleting job work units (work items and bill items) 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), inspection logic (September) and job logic (September).

Who will be affected?

This change will affect any users who work with job work units 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 job work units:

  • Through the Web API, where job work units are treated like any other item.

  • Through the Extended API, where logic specific to job work units is applied when performing the same operations (e.g. limiting the types of parent a job work unit 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 work unit item is operated on.

Linking Jobs and Job Work Units

When creating or editing a job, it isn't possible to manually create links to corresponding job work units (or change an existing links).

This is because linking is handled automatically during other processes:

  • When creating a job work unit, it will be linked to the parent job you specify.

  • When a job work unit is deleted, the link to its parent job will be removed.

  • When a job or job work unit is deep cloned, copies of both the job and job work units are created and linked together.

Job Work Unit constraints

A job work unit must be created with a link to a single parent job and a single work unit. Attempting to create one these will result in a BadRequest Error 1657715843.

Previously, if a job work unit had a custom parent in addition to its parent job, it was possible to clone that custom parent via this endpoint (see ReDoc).

POST /api/item/{id}/clone with cascadeModes set to Deep.

This would result in copies of the custom parent and job work unit being created and linked together. However, the job work unit would be missing the link to its parent job, which wouldn't be included in the clone operation.

This is no longer possible and will produce a BadRequest Error 1596183833 if attempted.

Automatic budget and estimated value

When creating a job work unit, if a budget or estimated value isn’t supplied, values for these will be copied from its linked work unit (if it holds any values for them).

Expected Release Date

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

Show Previous EntriesShow Previous Entries