Release Notes - 2022.02.09

Welcome to the second One Model product release for 2022! This article provides an overview of the product innovations and improvements to be delivered on 9 February 2022. You can see the full 2022 release schedule here: https://help.onemodel.co/en/articles/3134972-one-model-product-release-calendar.

User Experience Enhancements

Before this release when a user tried to Explore a tile from the Home Page they would get a security error unless they had the permission “CanEditHomePageDashboardTemplate”.
We have changed the way this feature works so that if a user has access to the data in a tile they are able to Explore it when they have the permission “CanExploreData”.
Naturally, while a user with the permission to explore the data is now able to do so from the home page, they are only able to update that tile in the home page if they have the “CanEditHomePageDashboardTemplate” permission. (ref 10332)

We improved the reliability of our SFTP Data Destinations by automatically retrying with a delay if there is a problem with the destination SFTP server. (ref 9357)
We've added some Retry logic for SuccessFactors in-case it is down for maintenance. (ref 10309)
We've added some new column name generation logic for the Workday Custom Reports processor so that we don't get duplicate column names. This can be enabled by enabling a flag in the Workday Custom Reports Data Source - but it will change any column names referenced by the Processing Scripts or Data Destinations. (ref 10031)

With almost all customers fully migrated to our newer user experience we have started to clean up old code and in this release the most notable one is the older feature to export a Dashboard. Flagging here for reference. (ref 10327)
We allow users to download a file containing all errored records in File and SFTP Data Sources. We fixed an issue where this file wouldn't open using a text editor. (ref 10307)
Fixed an issue where Processing Scripts could error at run-time because of Dimension Nodes or Descriptions that were longer than 128 characters. (ref 10291)
We ran into some temporal errors in our Redshift Data Destination due to the approach implemented for extracting and sending the data. We've simplified the approach which should prevent the errors from re-occurring. (ref 10173)
Fixed an issue where Redshift Data Sources would error if the table contained a double-quote (") character. (ref 10172)