Breaking changes and how to fix them

Overview of breaking changes introduced into Altinn Studio and how and what to update on an existing app to fix the problem.

På denne siden:

Breaking change: Property type changed for UserProfile.ProfileSettingPreference

Introduced with issue: #4466 and release v2020.28.
The change affects all applications in TT02 and PR with nuget version 1.0.98 and lower.

Errors

App doesn’t load only the blue background is visible.

How to fix

  1. Navigate to you application repository and find App.csproj in the App folder. Update nuget dependencies in App.csproj from 1.0.86. to version 1.1.0-alpha.
    <PackageReference Include="Altinn.App.Api" Version="1.0.86-alpha" />
    <PackageReference Include="Altinn.App.Common" Version="1.0.86-alpha" />
    <PackageReference Include="Altinn.App.PlatformServices" Version="1.0.86-alpha" />
    
  2. Modify the function ConfigureServices() in App/Startup.cs.

Include the lines below in the function. Anywhere would do, but we suggest referencing the memory cache after _ services.AddControllersWithViews()_ and the HttpClient in the same section as the other AppSI services.

services.AddMemoryCache();
services.AddHttpClient<IText, TextAppSI>();

Your code changes should match the image below.

Diff in code

Diff in code

Breaking change: New endpoint introduced in Altinn.Apps.Api exposing application text resources

Introduced with issue: #4451 and nuget 1.1.0.-alpha.
The change affects all application created in Altinn Studio before 8.07.2020 using nuget versions 1.1.0-alpha

Errors

How to fix

Once the nuget references are updated to version 1.1.0-alpha, modify the function ConfigureServices() in App/Startup.cs.

Include the lines below in the function. Anywhere would do, but we suggest referencing the memory cache after _ services.AddControllersWithViews()_ and the HttpClient in the same section as the other AppSI services.

services.AddMemoryCache();
services.AddHttpClient<IText, TextAppSI>();

Your code changes should match the image below.

Diff in code

Diff in code

Breakig change: Platform authorization introduced for Platform Register and Profile

Introduced with issue: #4162 and Release: v2020.23.
The change affects all application created in Altinn Studio before 03.06.2020.

Errors

Users will experience that instantiation, form filling and viewing receipt fails with the following error:

Unknown error page

Unknown-error

When checking the network log one will find that the POST request to https://ttd.apps.at22.altinn.cloud/ttd/apps-test/instances?instanceOwnerPartyId= fails with status code 404.

How to fix

There are three steps you must take in order to update your application to adhere to the breaking change.

  1. Update values.yaml in the deployment folder in your application repository. If no custom changes have been made to this file since you created the application, simply replace the content of the file with this code.
    The picture illustrates which changes are required in the file if you wish to do it manually, or inspect your code. Be ware that indentation is important when working with .yaml files. add new volume to values
  2. Update nuget dependencies in App.csproj to version 1.0.86-alpha. Navigate to you application repository and find App.csproj in the App folder. Upgrade the three Altinn.App nugetpackages to version 1.0.86.
        <PackageReference Include="Altinn.App.Api" Version="1.0.86-alpha" />
        <PackageReference Include="Altinn.App.Common" Version="1.0.86-alpha" />
        <PackageReference Include="Altinn.App.PlatformServices" Version="1.0.86-alpha" />
    
  3. Update Startup.cs in the App folder in your application repository. If no custom changes have been made to this file since you created the application, simply replace the content of the file with this code. The picture illustrates which changes are required in the file if you wish to do it manually, or inspect your code.
Update startup

Update Startup.cs

Breaking change: Updated client-side validation - frontend v2 and Nuget v1.0.82-alpha

Introduced with issue: #3944, and applies to existing apps that upgrade to the new major version of app frontend (v2).

The client-side validation of the app frontend has been replaced with a JSON-schema validation in order to provide a more complete client-side validation. As of v2 of app frontend, client-side validation has support for type-checking basic types, including enums. When upgrading the frontend version to v2, the app must use nuget versions 1.0.82-alpha or newer. See details below.

In order to implement this, we have made changes to how we bind the data model to fields in the forms.

The change is only breaking for apps using OR-type xsd (or have fields with `-`-character in xsd). Most Seres-type data models will not be affected, and will work without needing to make changes, even after updating to v2 of app frontend. If you do experience any problems with submitting/validating form data even with a seres-type xsd, follow the steps below.

Errors

For apps that use an OR-type xsd (or have fields with --character in xsd), the app may crash during submission/validation because the data model binding used does not match the true path in the json schema (and xsd). This is because we have been using a simplified path previously, to match with the C# model. We have now changed that so that the data binding name corresponds to the true xpath for the field.

How to fix

  • If using app frontend v2 or newer, make sure app is using nuget packages v1.0.82-alpha or newer. See documentation on how to update dependencies..

  • Open the app in altinn.studio and upload datamodel again to generate a new version of the model files, with all the updated paths.

    • Please note that this overwrites any texts in the text resource files, so make sure to save a copy or push the app to the app repo before doing this, to recover any texts that might disappear.
  • Update data model bindings in altinn.studio UI Editor, or update FormLayout.json with new data model bindings (see below for new format).

    • Each part of the path now corresponds to the xname of the field in the xsd. F.ex:

    XSD:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <!--title='Eksempel xsd skjema' lang='NOB'-->
  <xs:element name="Skjema">
    <xs:complexType>
      <xs:sequence>
        <xs:element minOccurs="0" ref="SomeGroup-grp-1111" /></xs:element>
      </xs:sequence>
      <xs:anyAttribute />
    </xs:complexType>
  </xs:element>
  <xs:element name="SomeGroup-grp-1111">
    <xs:complexType>
      <xs:sequence>
        <xs:element minOccurs="0" ref="SomeField-datadef-12345" />
      </xs:sequence>
      <xs:attribute fixed="1111" name="gruppeid" type="xs:positiveInteger" use="required" />
    </xs:complexType>
  </xs:element>
  <xs:element name="SomeField-datadef-12345">
      <xs:simpleContent>
        <xs:extension base="SomeTextformat">
          <xs:attribute fixed="12345" name="orid" type="xs:positiveInteger" use="required" />
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>
  <xs:simpleType name="SomeTextformat">
    <xs:restriction base="xs:string">
      <xs:length value="11" />
    </xs:restriction>
  </xs:simpleType>
</xs:schema>
  • Old format for data model binding: someGroupgrp1111.someFielddatatef12345.value.
  • New format for data model binding: SomeGroup-grp-1111.SomeField-datadef-12345.

Once the data model and bindings are updated, build and deploy app for the changes to take effect.

Breaking change: Error when attempting to create an instance as Application Owner

Introduced with issue: #3738.

The Register API had a few GET operations that took an input parameter through the body of an http request. Requests against these operations would work in AT environments, but would be broken by API Management in production like environments. The operations in question has now been removed and replaced with operations that require POST requests.

Errors

The methods that have been removed were used by an app when an instantiation were done by the Application owner. More specifically if the instanceOwnerPartyId were unknown. The instantiation request would then have the Person number or organization number instead, and the Register operation would be used to identify the correct party id.

POST https://{org}.apps.tt02.altinn.no/{app-id}/instances/

{
  "appId" : "org/app",
  "instanceOwner": {
    "personNumber": "12247918309",
    "organisationNumber": null,
    "instanceOwnerPartyId": null
  },
  ...
}

How to fix

Any issues related to this change can be fixed by upgrading to the latest version of Altinn.App.PlatformServices. This means the App must be updated and a the new version deployed to all environments. Existing instances are not affected.

Breaking change: Deploy pipeline fails with error: UPGRADE FAILED

Introduced with upgrade of AKS cluster. The api version (extensions/v1beta1) used to deploy apps to the AKS cluster is no longer supported.

Errors

When triggering deploy from altinn.studio the deploy fails. On closer inspection of the pipeline (byggloggen) the error message below is shown at the end of the failed step.

Console error message

Helm upgrade error

How to fix

To fix this issue the deployment to use a new api version. Navigate to you application repository and find deployment.yaml. It is placed in the folder deployment/templates.

Make the changes spesified below to the file, and update the repository. Remember to pull the latest version in altinn.studio before attempting to re-deploy.

Code diff view

Helm upgrade error fix

  • Change apiVersion from extensions/v1beta1 to apps/v1.

  • Add the following lines under replicas in the spec section. Be ware of indentation here. Two spaces are used as indent for sub sections.

selector:
  matchLabels:
    app: {{ template "name" . }}

Breaking change: Send-in / Validation fails with ‘Ukjent feil’

Introduced with issue: #3927.

There was a vulnerability in the solution allowing to update a whole instance object using an endpoint in app backend or storage. This has been solved by refactoring app backend and removing the endpoints.

Error

When sending in an instance after completing form filling the error below i prompted. In network you can see that the ‘validate’-request receives a 500 code in response.

Error page

Send-in error

How to fix

Navigate to you application repository and find App.csproj. Upgrade the three Altinn.App nugetpackages to version 1.0.78.

<PackageReference Include="Altinn.App.Api" Version="1.0.78-alpha" />
<PackageReference Include="Altinn.App.Common" Version="1.0.78-alpha" />
<PackageReference Include="Altinn.App.PlatformServices" Version="1.0.78-alpha" />

Breaking change: Validation fails for attachments in some cases after 30.03.2020

Introduced with issues: #1925 and #3915.

In Altinn Studio, all data types that were created from a FileUpload component were set with allowedContentTypes: [application/octet-stream] as default.

This was also set for all uploads from the app. This has now been changed, so that the file types defined by the app developer are also set in allowedContentTypes, and the file upload is sent with the corresponding Content-Type of the file in the request header.

Error

Apps that were created before the fix was implemented (30.03.2020) may experience that validation fails for the attachment, even though it is of the correct format specified in Altinn Studio. This is because the dataType for the attachment expects application/octet-stream, but instead receives the actual mime type for the uploaded file.

How to fix

Update allowedContentTypes for the data type that fails. This can either be done manually in the applications applicationMetadata.json for the affected data type(s) or by updating the FileUpload component in Altinn Studio so that the expected allowedContentTypes are saved.

After updating, the app must be re-deployed.

Breaking change: Build fails after upgrading Altinn.App-nugets to version 1.0.62-alpha

Introduced with issue: #3820.

The base class that every application inherits has been altered to allow for both data and task validation.

Error

When building App.cs errors simillar to those depicted in the picture below are logged.

build-errors

Build errors

How to fix

If you haven’t made any changes to App/logic/Validation/ValidationHandler.cs and App/logic/App.cs the quickest way to fix the build errors are to copy these files from the template and paste them into your repository. Find the template files here.

If changes have been made to these files, follow the instructions below to fix the errors.

App/logic/Validation/ValidationHandler.cs

  1. Add a reference to Altinn.Platform.Storage.Interface.Models by including the snippet below amongst the using statements.
    using Altinn.Platform.Storage.Interface.Models;
    
  2. Add the function below in the class.
    public async Task ValidateTask(Instance instance, string taskId, ModelStateDictionary validationResults)
    {
        await Task.CompletedTask;
    }
    

App/logic/App.cs

  1. Rename function RunValidation to RunDataValidation
  2. Add the function below in the class
/// <summary>
/// Run validation event to perform custom validations
/// </summary>
/// <param name="validationResults">Object to contain any validation errors/warnings</param>
/// <returns>Value indicating if the form is valid or not</returns>
public override async Task RunTaskValidation(Instance instance, string taskId, ModelStateDictionary validationResults)
{
    await _validationHandler.ValidateTask(instance, taskId, validationResults);
}