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

This month's release brings a few small, yet mighty changes to Alloy. Here's a quick run-through of the highlights of this release. If you would like to see the full list of everything included in this release, take a look at https://releases.alloyapp.io

Character Limit Removed from Defects Description

The Description attribute which appears on all Defects designs previously had a character limit which was just too low for most uses. As part of this release, we have removed this limit, allowing you to use the attribute to store much more detail about defects.

Locations of Interest

Included in this release of Alloy Mobile, is a shortcut method for navigating to your workspace's locations of interest. The menu bar now includes a Locations of Interest (LOI) option, which will bring up your LOIs in a drawer list. Tapping the location pin of an LOI in the list will open the location in available mapping applications on your mobile, allowing you to navigate to the location.

We envisage this helping with things like needing to navigate to a tip if you're on a waste collection round and need to empty a vehicle, or to navigate back to a depot. The list can also be sorted and filtered, as an example, for times when you may need to find the closest LOI.

This feature is currently only available on the Android version of Alloy Mobile, we hope to bring this feature to iOS soon.

Full-Screen Job Work Item Editor - Mobile

Also included in this release of Alloy Mobile is a new experience when managing your Job Work Items. A new widget has been added to represent Job Work Items on Jobs, it gives you more of an overview of estimated and actual values and makes it much easier to quickly enter these figures whilst on a job.

This feature is currently only available on the iOS version of Alloy Mobile, we will be introducing it to the Android version soon.

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

Overview

As part of the ongoing changes to the Extended API, we have updated the Web API to now handle the logic associated with Applicable Types. This ensures that items cannot be created linked to parents that are not compatible or applicable to that item. The Applicable Types logic only governs the creation of Jobs, Inspections and Defects to Assets and Job Work Units to Jobs.

This change also includes the creation of new endpoints on the API to handle listing and managing Applicable Types. Attempting to create an item that is governed by applicable types, to a parent item that is not applicable will result in an error.

Who will be affected?

This change affects all users who create Jobs/Inspections/Defects through the Web API directly or through the Create Item process on the Web Frontend. Whereas previously it was possible to create items that did not adhere to Applicable Types, this will no longer be possible.

Details

Currently, it is possible to create Jobs/Inspections/Defects/Job Work Units through the Web API and set the parent asset or job, regardless of the design. Therefore bypassing the logic implemented on the Extended API through Applicable Types. This created the possibility for inconsistencies as users from one service area could raise items against incorrect parents from another service area.

To support this change, a number of Applicable Type filter designs and attributes have been deprecated and will be set to customer context:

designs_jobFilters 

designs_jobFilterApplicableTypes

designs_inspectionFilters 

designs_inspectionFilterApplicableTypes

designs_defectFilters

designs_defectFilterApplicableTypes

attributes_workItemsAppliesTo

designs_workItemApplicableTypes

Two new designs designs_applicableTo and designs_applicableFilter have been created as part of Core blueprints to handle Applicability across Alloy. 

designs_applicableTo

designs_applicableTocontains two string attributes that describe applicability:

attributes_applicableFrom - Can contain a Design or Design Interface Code or ItemID

attributes_applicableToTo - Will contain a Design or Design Interface Code

Values in attributes_applicableFrom are considered applicable to the corresponding values in attributes_applicableToTo.

designs_applicableFilter

designs_applicableFilter holds information that defines the validation rules applied by the Alloy Engine that were previously hard-coded. The design holds the following attributes:

attributes_applicableFilterLink - a string attribute containing a link attribute code. Changes to this link attribute will be validated against the applicable types. The design containing this attribute will be treated as "to" side of the filter and the design it links to will be considered the "from"

attributes_applicableFilterFrom - a required string attribute that contains the design or design interface code that of the "from" side of the applicable type

attributes_applicableFilterVia - an optional string attribute containing a link attribute code. This is a child or parent link that changes the "to" side of the applicable type to be the child or parent items

New API Endpoints

The following new endpoints have been added to the Web API to allow management of the new applicable types:

/api/applicable-type/applicable-to - Lists applicable to types

/api/applicable-type/applicable-from - Lists applicable from types

/api/applicable-type/add - Add applicable types

/api/applicable-type/remove - Remove applicable types

The existing applicable types endpoints on the Extended API will not be removed. Calls to these endpoints will be re-routed through the new endpoints automatically.

Expected Release Date

This change will be included as part of the v2.37 release of Alloy on 30th June 2022

As an extra special treat, this month contains not one, but two Alloy updates! As such, we are really excited to announce the second Alloy update for May. Here are some of the highlights of this release.

Trigger Workflow from Items

We have had the ability to create manually triggered workflows for a few months now, this feature extends that feature by providing the option to trigger those workflows from an item.

This would allow you to create custom complex actions for particular designs and for people to carry them out easily through a single selection.

When setting up these Workflows, you may only want some users to be able to trigger them, you can control this by setting Read permissions for those users. Any user who does not have Read permissions will not be able to trigger it.

We've been looking forward to this feature and are really excited to see what creative uses for this everyone produces. For uses such as completing all jobs on an item, creating an invoice or emailing a supervisor, the possibilities are endless.

Workflow Emails - Multiple Recipients

Previously, whenever you wanted your Workflow to send emails to multiple email addresses, you would need to create a separate node for each recipient. This update will now allow for multiple recipients to be listed under the Email To field. 

Just keep in mind that each recipient address will need to be delimited using a comma (,). When a Workflow is triggered with this set up correctly, an identical email will be sent to each of the addresses listed.

AQS Builder Relative Dates

Workflows have been able to define relative Dates and Times for a long time, but this useful piece of functionality has, until now, been missing from the AQS builder.

You can now use a relative date time as a comparator to other compatible attributes or values. This is particularly useful when you are defining saved queries as you no longer need to update any date values that are filtering your data to a specific time period. For example, you can create a saved query to display all Jobs raised within the last two weeks. 

The point in time from which the relative date time is taken from can also be configured to the following options:

• Now
• Start of Today
• End of Today
• Last Monday
• Start of the Week
• Start of the Month

Custom Reports on Items

An improvement has been made to the Reports pane. Due to a slight difference in how Standard and Custom Reports are linked to items, the Reports pane used to only show Standard Reports. This has now been changed to include any Custom Reports that have been linked.

To ensure that reports are linked to the Item they report on, when creating an Item Data Source in the Report Builder, be sure to check the option to Link report to item?

Task Assignment Current Date

We have been hearing some great feedback recently about the Task Assignment view, we also have a lot of great suggestions on how to make it a bit more user friendly. One of those changes present in this update is a small marker highlighting the current date, hopefully making it a bit easier to orientate where you are on the planner. 

 Alloy Community

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

Overview

An option to export data as either a CSV or ESRI SHP file was introduced to the API in v2.32. This choice was added to the request model for the Data Export endpoint via a discriminator. When this was initially introduced, the discriminator was optional and if not supplied, would default to CSV. Since v2.35 the discriminator is now required when making calls to this endpoint.

Who does this affect?

This change affects API users of the Export endpoint. Web users are not affected.

Details

The following endpoint:

POST /api/export

now requires a value passed for discriminator which can currently take one of two options:

• ShapefileExportWebRequestModel requests made with this model will return files as SHP.
• CsvExportWebRequestModel requests made with this model will return data as a CSV. 

Not providing a value will now result in an error being returned.

Expected Release Date

This change was included as part of the v2.35 release of Alloy on 5th May 2022. We would like to apologise for any inconvenience this has caused.

Overview

As part of ongoing improvements to the Extended API, we are changing the way we consider required attributes on creation of activities through the API. This change is being made to ensure consistency with other endpoints as to how what 'Required' means when considering attribute values being supplied to the API by the caller.

Who will be affected?

Any users of the Extended API who rely on the geometry of created activities being inferred from the parent Asset will be affected by this change.

Details

Currently, it is possible to create an activity such as a Job or Defect via the Extended API and not provide geometry despite the activity Design having the geometry marked as required since the geometry may be inferred from the parent Asset. This has created an inconsistency where required attributes are not actually required.  

In order to remedy this inconsistency, we are making a change to ensure that values for all required attributes are always supplied by the caller of the API. For simplicity, the end result will be:

Required means required 😀

For activities where geometry and possibly other attribute values are not supplied but computed by a service/backend process, these attributes should be marked as optional. This ensures data consistency in the event that the backend process is unable to compute an attribute value for any reason.

Avoiding a Breaking Change

As part of this change, we will be updating all activity designs, including custom designs where possible to mark the geometry as optional to ensure that any integrations that rely on the previous interpretation are not affected by this change in behaviour.

Expected Release Date

This change will be rolled out over multiple releases starting from the end of May 2022.