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?
We're excited to announce this month's Alloy update! This release will be applied during the evening of May 5th. In this post, we'll have a look at the highlights included in this release. For a full list of all changes included in this release, have a look at the Alloy Changelog.
You can also discuss this post in the Alloy Community here: Alloy Community
We're excited to present the new navigation feature we have added to Item Audit logs. This enhancement will allow you to quickly flick through the audit history of an item and see the before and after for the change side by side.
We hope this will be a welcome change but let us know your thoughts in the comments.
A change made in this release will improve the usability of the Street Manager Apply for Works process. Information already captured on the Job will automatically be pre-populated in the Permit Application.
This includes details such as USRN, Works Location, Workstream, Works Description, Start and End Dates & Times and Permit Conditions.
Photos taken through Alloy Mobile can now have the local date and time stamp burnt into them. This is particularly useful for evidencing Defects or the completion of Jobs. This is optional and can be found in the settings menu.
A new 'Selected' tab has been added to Alloy Mobile. This tab allows you to quickly filter the list by items that have already been selected, instead of having to scroll through long lists of unselected items. This feature is available on both Android and iOS.
Another change made in Alloy Mobile in this release is an update to the UI used in the settings menu. With the addition of more items in this menu, we have categorised the available options to make finding the setting you require a bit easier.
Welcome to the first release update through our new in-app notifications widget! This month's release holds a bunch of great new features and updates. All these new features will be available in the evening of March 31st (GMT).
Discuss this post in the Alloy Community here: Alloy Community
A new stencil control has been added in this release. It takes a geometry attribute as a parameter and displays an image of the respective area taken from Google Street View. Clicking the image will open a new tab and take you to the Google Street View application and navigate to the area displayed.
It's always frustrating running into errors, we hope with this new feature, we can make it easier to find answers to what's causing the issue.
The error message window has been updated to provide you with links to suggested articles on the Alloy Community site.
By the way, have you had a look at Community yet?
The error message will search community for any articles that include the supplied error code, sharing solutions others have found or official guidance from the Alloy team on how to resolve your issue.
If you still need the full details of the error message response, simply click the code button in the top right of the message to view the full error message or click the bottom button to copy everything to the clipboard.
Are you the type of person who loves to have all the tabs you need open and to be able to quickly change and switch between them? If so, we've made the Data Explorer much easier for you. A small but significant change in this update is the addition of a couple of scroll buttons in the top right hand corner, allowing you to scroll along the tab bar.
Ever created a great report, then realise you need to create another one that is almost identical apart from one small change? This new feature makes that simple to achieve. Custom Reports can now be cloned, creating another report with the same configuration but with a different name. This avoids having to re-create the second report from scratch to match the first.
We're adding a new option when exporting data from the Data Explorer, not only can you get your data in a .csv file, but now you'll be able to get your data as a .shp file too. When exporting data, you'll now be presented with an extra option in the modal to select SHP file type.
The export will create a .zip file to contain the multiple files that are associated with this data type.
With our change to this new format of celebrating our releases, you may be asking: "What about all the other changes you've made?" If you'd like to get a full list of all our changes in this release, do head over to our changelog.
Welcome to the all new notifications section in Alloy. Here you will find highlights to showcase new features and updates coming in each new release. We hope that this will help you get to most out your Alloy system.
You can still access all announcements including API updates by visiting our announcements site at https://announcements.alloyapp.io.
If you have any feedback on this change or any other, we would love to hear from you so get in touch at product@weareyotta.com.
Discuss this post in the Alloy Community here: https://community.alloyapp.io/c/announcements/
Overview
We are adding an new option to the data Export endpoint which allow you to specify the projection to be used for Geometry data by providing the Proj4 string to use to convert over from WGS84 (Lat-Long)
Who does this affect?
This change will affect API users of the Export endpoint but will not modify the existing behaviour if the optional setting is not provided.
Details
The following endpoint:
POST /api/export
now accepts an optional string proj4 that may be used to convert geometry coordinates into the spatial reference system of your choice. This mirrors the optional Proj4 setting used during import.
Without the proj4 string, geometry is exported in WGS84 (Longitude, Latitude) coordinates.
There is a database of PROJ4 strings available for searching here https://epsg.io/
For example, for the UK British National Grid system, the Proj4 string is
+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000 +y_0=-100000 +ellps=airy +datum=OSGB36 +units=m +no_defs
Expected Release Date
13th January 2022
Overview
We are adding a new feature that will allow administrators to specify the specific method of authentication (such as Microsoft Online SSO) to use in order to access Customer Projects.
Who does this affect?
This change will affect administrators who want to restrict their users to using a specified authentication method over the current choice of email/password or SSO options including Google and Microsoft. Note that these policies may only be configured using Alloy Forge so please contact the Support Team to change the way in which users access your project.
Details
This change has introduced a new concept called "Customer Security Policy". In simple terms, this is an object contained in the Customer document that is meant to include information about customer choices in terms of security related "settings".
Currently the security policy only includes the accepted authentication method property. If set, a user can only create a customer session for a specific customer if that session is created through one of the accepted authentication methods. Normally a customer session is created by switching a master session to a customer session. This means the master session will need to have been created through one of the accepted authentication methods.
If the user utilises an authentication method not on the accepted list, an error message will be presented and the user returned to the logon screen to retry.
The security policies may be set using the following Forge endpoints:
GET api/customer/{id}/security-policy - Gets the customer security policy for a specific customer
* PUT api/customer/{id}/security-policy - Edits the customer security policy for a specific customer
Expected Release Date
13th January 2022
Overview
We are adding a new option to the Data Export endpoint which allow you to set the export format to ESRI SHP (Shape) file instead of the standard CSV export.
Who does this affect?
This change will affect API users of the Export endpoint who require ESRI shape file output.
Details
The following endpoint:
POST /api/export
can now be used to specify the export type as ESRI SHP. Note that due to length constraints in the SHP format for field data, attributes values may be truncated in the exported files.
The endpoint now accepts two different request models:
ShapefileExportWebRequestModel requests made with this model will return files as SHP.
CsvExportWebRequestModel requests made with this model will return data as a CSV.
Both these models extend the ExportWebRequestModelBase model.
Note the the SHP format consists of multiple (3) files that will be returned on the Export File endpoint as a zipped bundle.
Expected Release Date
13th January 2022
As part of ongoing improvements, we are updating the way API keys are managed in the system. This change will see the provision of an API key to every user discontinued, with future keys being generated on demand using the new mechanism described below. As part of this change, the way in which the keys are provided to the API as a token header will change to use the Bearer Authentication method.
This change will affect all API users as any existing API key in use will be retired based on the timeline specified below, with the expectation for all users to transition to the new keys by that time.
A new mechanism for API keys has been added and alongside it, a new series of endpoints. The current API key mechanism, where all users have an API key created alongside them is obsoleted and will be removed as part of Phase 2.
Ignoring the current mechanism, new users will not have API keys created by default, but instead, will be able to create them on demand up to a maximum of 100 keys per user per customer. The new API keys will also come with a label field (to provide some description), an enabled flag (if false the API key will not be valid for usage), and an optional expireAt datetime (if an API key is expired it cannot be edited nor used to authenticate, it can only be deleted).
An API key value (or token) will never be shown after the creation of the API key, so if an issued API is lost or forgotten then the user will need to generate a new one. The database only contains a one way hashed version of the key, just like for passwords, so it is not possible for anyone to impersonate the user using the key even if they have direct access to database.
The new endpoints are as follows:
GET api/api-key/{id} - Allows the caller to get the information of an API key by its ID
GET api/api-key - Allows the caller to list API keys by user and customer. Optionally it accepts a filter for the "label" field
PUT api/api-key/{id} - Allows the caller to edit an API key to change the label, enabled flag and expiration
POST api/api-key - Allows the caller to create an API key, this is the only endpoint that will return the actual value of an API key
DELETE api/api-key/{id} - Allows the caller to delete an API key
The new API keys will need to be passed according to the OAuth 2.0 Bearer token format (RFC 6750). That is a request header named "Authorization" will need to be included, which would look like this:
Authorization: Bearer APIKEYVALUEHERE
This change means that the API keys provided by the old and new mechanisms are not interchangeable and old keys will not be accepted via the Authorization header and new keys will need to be generated.
No, each key is specific to a user and customer project. Customers with Live and Staging environments should consider these separately as there is no link between projects across environments.
No, by default each API key will have no expiration date set and it will be the responsibility of the user to set this on creation or edit.
In line with best practice, the API key will only be given in the response model on creation. It will then be the creator's responsibility to safely store this key for later use. Only the associated data for the API keys (such as the label, enabled flag and expiration date) will be provided in the GET, PUT and DELETE responses.
Once you've authenticated using your login credentials via the session endpoint and created a customer session, you'll be able to use the customer session token to generate and manage keys using the endpoints described above. So no, you won't be stuck in a infinite loop trying to get an API key 😜.
26th January 2023
We are making a temporary change to the behaviour of how the results from an AQS Query Data Source are displayed in custom reports. This change will affect the display in controls when linking to multiple items to make this work consistently across all attribute types.
This change is being made to prevent report generation from failing under certain conditions described below.
This change will affect anyone using the AQS Query Data source with join attributes within the Report Builder to build custom reports.
Previously, when an AQS Query resulted in multiple matched items for join attributes, this would be displayed as X Items into the resulting table cell in the report. However, since all entries in a table column must be of the same type, this would only work for String attributes (since the entry X Items is also a String) and would result in an error for other attribute types with the report failing to generate.
From now on, resulting cells will show a single item attribute result, similar to the current behaviour of the single join result. If multiple values are matched, only the first attribute of the first item will be displayed.
Let's assume there is a project containing 4 job tasks. If the user would create a custom report using an AQS Query data source rooted on Projects and linking to Jobs via the Tasks Attribute (Project DS -> Tasks to Jobs DS -> Title). If a Table control was then added to the layout based on this data source, the display of the data in this table will change following this change.
Before Change
Previously, the table would have shown 4 Items in the joined Tasks and Title column.
After Change
However, from now on this would display one of the job titles e.g. JOB-9.
Note
If you would like to continue using this aggregation, this can be achieved by using a Join Data source rather than an AQS Query Data source.
AQS expressions now support the ability to run queries with conditions on an item level count.
All existing users will be able to take advantage of this feature through the newly added AQS Count node.
An item level count allows to have a condition on the number of items connected through a link attribute being equal, greater than, etc. to the value of another attribute on the same item.
Example Use Case
As an example, we can consider a query that wants to fetch the title and subtitle of all projects that are over capacity. That is all projects that have a number of tasks greater than or equal to their capacity, contained in attribute attributes_projectsCapacity_60464441c14e5d000ad7e47.
{
"type": "Query",
"properties": {
"attributes": [
"attributes_itemsTitle",
"attributes_itemsSubtitle"
],
"collectionCode": [
"Live"
],
"dodiCode": "designs_projects"
},
"children": [
{
"type": "GreaterThan",
"properties": {
"inclusive": true
},
"children": [
{
"type": "Count",
"properties": {
"groupBy": "attributes_projectsTasks"
}
},
{
"type": "Attribute",
"properties": {
"attributeCode": "attributes_projectsCapacity_60464441c14e5d000ad7e479"
}
}
]
}
]
}Prior to this change, users could only compare a count node against a static Number node.
