Ometa Framework Release v6.0.0

Below you can find important information regarding the 6.0.0 release of the Ometa Framework. As this is a major version, breaking changes might be applicable.

Before Upgrade

1. Analyze the changes.

2. Ensure you have a certificate for integration with SharePoint Online and/or the Graph API (if not already present). See this article regarding this breaking change

3. Double-check your custom code for SharePoint ClientContext creation. Make sure each ClientContext is created via our static SharePointAuthentication class of the Ometa.Utilities.Client library. Don't use the SharePointOnlineCredentials class.

   public class YourCustomClass : IRequestProcessor
   {
       public IInterfaceRequest Interface { get; set; }
   
       public async Task ProcessRequestAsync(CancellationToken cancellationToken = default)
       {
           // Don't do this:
           var spCredentials = new SharePointOnlineCredentials(username, securePassword);
           using (var clientContext = new ClientContext("https://mysharepoint.sharepoint.com"))
           {
               clientContext.Credentials = spCredentials;
               clientContext.Load(clientContext.Web, w => w.Title);
               clientContext.ExecuteQuery();
           }
   
           // Instead do this:
           using (var clientContext = await SharePointAuthentication.CreateClientContextWithAzureAdCertificateAsync("https://mysharepoint.sharepoint.com", clientId, certificateSubject, "mysharepoint.onmicrosoft.com", Interface.Log))
           {
               clientContext.Load(clientContext.Web, w => w.Title);
               await clientContext.ExecuteQueryAsync();
           }
       }
   }
   

4. Check there are no DLL profiles still using Isolation : Dedicated, follow the migration guide and change them to Isolation : Default otherwise.

5. Recompile your custom DLL's against the Ometa nuget package of this new framework version, resolve the errors and use our guidelines.

6. There has been an update in the accounts article, to work with service accounts and no longer with local admin accounts. Follow the recommendations in this article.

7. Validate the database migration using the Employee Migration Script. Run this script on the framework database before running the setup.

   Note

   When the Employee Migration Script returns an index error, such as The index ‘CaseTypeStatus_QueueTypeID’ is dependent on column ‘CaseID’, it is most likely because you created a custom index on this table. You need to remove your custom index manually and recreate it after upgrading the framework.

During Upgrade

DBMigration

The DbMigration.exe gives the error: The database must migrate the [Employee] data into the [Person] and [User] tables but this must be validated first before it can be done safely ...

Run the Employee Migration Script in SQL Server on the Ometa Framework database and press enter to retry.

After Upgrade

1. Update all profiles towards SharePoint Online and the Graph API (REST/OData) to use a certificate. Don't forget the Mail Building Block profile(s) which use the Graph API.

   Important

   The following authentication methods will not work anymore towards SharePoint environments:

   • Client Id and Secret
   • Azure Key Vault
   • For SharePoint Online: email and password

   The following authentication methods work:

   • For SharePoint Online: Only Azure AD Certificates
   • For SharePoint On-premise: Username and password

   

   

   

2. Open the global appsettings.json and check if AppSettings.SharePointAuthentications is filled out. If filled out check if the config.SharePointAuthentications and config.SharePointRewriteUrls database tables are filled out accordingly.

   • If not filled out, you can run the DBMigrator tool manually: %OMETA_INSTALL_ROOT%\Ometa Software Suite\TopDir\BC\Bin\DbMigration\Ometa.Framework.Infra.DbMigration.exe. Make sure to Recycle the
   • Fill the database entry/entries manually. Update the SharePoint authentication(s) of the Generic REST service. See the Generic REST SharePoint Settings for more information.

3. Remove the %OMETA_INSTALL_ROOT%\Ometa Software Suite\Services\Generic REST Service\appsettings.json if this still exist.

4. Remove the following entry from %OMETA_INSTALL_ROOT%\Ometa Software Suite\appsettings.json:

   "AppSettings": {
       "EnableCompression": true,
       "CoreServiceUrl": "https://ometa-core.example.com",
       "UseUnsafeUserContext": false,
       "SharePointAuthentications": [
           { 
               ...
           }
       ],
       "SharePointRewriteUrls": [
           {
               "FromUrl": "https://yourcompany.sharepoint.com",
               "ToUrl": "https://yourcompany-internal.sharepoint.com"
           }
       ] 
   },
   

5. Set up the new Case Management Dashboard

6. Remove the apps in the app catalog and add the new obiz-suite-apps.sppkg

7. Remove the ACS settings

8. Apply the new IIS Settings for the Ometa Authority, Core and Generic REST Service (preload and start mode)

9. Run the optional SQL command to free disk space.

SharePoint Online web parts

All the Ometa Suite web parts (Adm, Smart Tiles, Security Redirect) are combined into one solution instead of separate applications. This optimizes the deployment and upgrade process of the web parts.

The new solution uses the same id for the web parts as the previous applications. This means that the previous applications have to be removed to prevent conflicting ids. This includes Ometa ADM, Ometa Smart Tiles and Ometa Security Redirect.

Previous apps that have to be removed

New app that contains all the web parts

Remove Legacy ACS App Principals Settings

Azure Access Control Service (ACS) will be retired on April 2, 2026. Therefore, it is a best practice to remove any remaining ACS settings. These settings often grant excessive permissions (full control) to app registrations, posing a security risk. Removing them ensures least privilege and avoids potential conflicts after ACS is decommissioned.

The screenshot below shows the retired way of granting application permissions in SharePoint.

To navigate to the app principals page in SharePoint, follow these steps:

1. Open your web browser and go to the appropriate URL:
   • Tenant-wide: https://yourtenantname-admin.sharepoint.com/_layouts/15/appprincipals.aspx (Replace yourtenantname with your actual tenant name.)
   • Site-specific: https://yoursitecollection.sharepoint.com/_layouts/15/appprincipals.aspx (Replace yoursitecollection with the URL of your site collection.)
2. Log in with your SharePoint administrator credentials if prompted.
3. Review the list of app principals. Locate the app principal associated with the retired ACS app (using the App ID). Consult your application registration documentation or Azure Active Directory to identify the correct App ID. Remove the relevant app principal.

⚠️ Breaking Changes

⚠️ SQL Server 2012 - 2014

SQL Server versions 2012 and 2014 are no longer supported. Using these versions may lead to potential issues and breakages. We strongly recommend upgrading to SQL Server 2016 or a newer version to ensure continued compatibility and receive the latest updates and security patches.

⚠️ Windows Server 2012

Windows Server 2012 is no longer officially supported. As a result, Ometa cannot guarantee the proper functioning of the software on this platform. To ensure a stable and supported environment, we advise upgrading to Windows Server 2016 or a newer version.

⚠️ SharePoint Server 2013 - 2016

SharePoint Server 2013 and 2016 are no longer supported. Consequently, SharePoint solution packages (wsp) will no longer be delivered or maintained. To take advantage of the latest features, security enhancements, and ongoing support, we recommend upgrading to SharePoint Server 2019 or a newer version. Alternatively, consider transitioning to SharePoint Online for a more modern and cloud-based collaboration experience.

⚠️ Microsoft ACS Retirement

Authentication towards SharePoint using client id and secret is not supported anymore due to retirement of Microsoft ACS. See this article for more information.

⚠️ Case Management Dashboard

The Case Management Dashboard is taken out of SharePoint. Follow the article to set up version 2 of this dashboard.

The Case Management Dashboard which was provisioned in SharePoint will no longer be supported because it was still using classic SharePoint pages. The Case Management Dashboard v2 is taken out of SharePoint and is part of the Obiz Suite.

Follow this article to set up the new dashboard.

⚠️ Ometa.Utilities.Client library now uses Pnp.Framework

The Ometa.Utilities.Client library has been completely migrated to use the Pnp.Framework.

Because of this change, many code bases using this library have been impacted and have also been adjusted (e.g. the SharePoint interface, Ometa.DCS and its components, Generic REST, ...).

All these adjustments can and most likely will have an impact on your custom code using the Ometa.Utilities.Client, Ometa.DCS, or other Ometa libraries.

After updating your custom code project(s) to use the Ometa nuget packages of this new framework version, you'll have to resolve the compiler errors.

Most of them will be a change in the function invocation to an async version:

public class YourCustomClass : IRequestProcessor
{
    public IInterfaceRequest Interface { get; set; }

    public async Task ProcessRequestAsync(CancellationToken cancellationToken = default)
    {
        using (var bcClient = Interface.ConnectedClient.CreateNewClient())
        {
            using (DCSClient dcsClient = new DCSClient(BCClient))
            {
                var aCase = dcsClient.GetCase(54);
                aCase.Description = "New Description";
                aCase.Save(); // This will generate a compiler error.
                await aCase.SaveAsync(); // This is the new way of saving the case.
            }
        }
    }
}

⚠️ Preserved Function Names

In CSL, when targeting the default out-of-the-box functions such as ‘Detail’, ‘Edit’, and ‘New’, there could be an ambiguous call if you also had your own functions with the same names. This prevented you from targeting your own functions. A workaround was to rename your own functions to ensure they could be properly targeted.

We have removed this support, and you should now use the following reserved names to target the default out-of-the-box functions.

Preserved name	Target
$$obiz-New	Creation view
$$obiz-Edit	Update view
$$obiz-Update	Update view
$$obiz-InlineEdit	Inline edit function
$$obiz-Details	Single Record view
$$obiz-Refresh	Refresh function
$$obiz-Export	Export function
$$obiz-ContextSetter	Context Setter function
$$obiz-AuditTrailDetails	Audit Trail view

Azure Key Vault Authentication

Authentication using Azure Key Vaults will be removed in v6. We recommend using certificate authentication instead. See this article for a guide on configuring authentication using certificates throughout the framework.

Ensure Modern Team Site Building Block has been removed

As the basic authentication and client ID and secret authentication is dropped in this version and the SharePoint API for this function only supported basic authentication, this building block cannot be supported anymore. The method for this building block has been removed. If you want to create SharePoint site with a Teams group you should look into using the Graph API to create the Team.

Ensure Web Part Page Building Block for SharePoint Online

Due to recent changes in SharePoint’s behavior to enhance security by preventing custom scripts, we have made necessary adjustments in this feature release. The 'Ensure Web Part Page' building block will fail if the NoScript setting is enabled on the site. A clear message will be shown if this property is enabled and the building block fails. This building block will keep working if you manually disable the NoScript property for the site before triggering this building block.

For more details, please refer to the official Microsoft documentation.

Custom DLL Isolation: Dedicated

Custom code can no longer use Isolation : Dedicated in the profile. This was previously available for DLL code from v4.x that was not yet migrated to the new structure implemented with multi threaded interface processes. The field will be removed from all DLL templates and profiles and will function like Isolation : Default did in v5.x.

The deprecated properties on the static Interface class have also been removed, as they were only kept for backwards compatibility using Isolation : Dedicated. Implementing IRequestProcessor and using the Interface property remains the correct syntax for writing custom code for use in the Ometa framework.

If there are still DLL profiles that use Isolation : Dedicated, they will no longer work and the code must be migrated. See the migration guide for more information on how to migrate code.

Building Blocks

Due to recent changes in SharePoint’s behavior to enhance security by preventing custom scripts, we have made necessary adjustments in this feature release. As a result, we have removed support for the following Building Blocks, which required setting NoScriptSite or DenyAddAndCustomizePages to false:

• SharePoint.BuildingBlocks.UserCustomActions - Delete User Custom Action
• SharePoint.BuildingBlocks.UserCustomActions - Ensure User Custom Action

The following fields are removed from the SharePoint.BuildingBlocks.Permissions - Ensure Group building block:

• Set As Default Visitors Group
• Set As Default Members Group
• Set As Default Owners Group

This change was essential to align with Microsoft’s updated policies.

Historical Case Property Id: Int -> BigInt

We've changed the datatype of the ID column in the historical case property from int to bigint.

This could cause compilation errors in custom code when working with the Id property of historical case properties. If you encounter this, change your code to use the long type instead.

BAM Database

Several columns are removed from the Log table:

• EventId
• ProcessName
• MessageTemplate
• ParentId

They are not replaced by another feature as they either only took up unnecessary space, or provided no value at all for issue resolution when looking and filtering through the log data.

All queries reading from the Log table provided by the framework are adapted to work accordingly.

User written queries will have to modified manually by removing all the name references to those dropped columns.

Removal of jQuery Function

jQuery was a default library which was loaded into the already retired Kendo ADM. When migrating from Kendo ADM to ADM you needed to revise all custom JavaScript code since the jQuery $, and $fw variables couldn't be used any longer.

When you still used the jQuery, $ and $fw variables your custom scripts (on load complete script, configuration scripts, view field events, ...) was not executed and an error was thrown in the console stating the following:

// The following script uses jQuery, but jQuery was not found on the page:
var pageData = CSL.grid.getPageData({ gridId: sourceId, returnNames: true });

source.find(".go-to-site").each(function(index, item){
    [ERROR]--->$fw(item).on("click", function(event){
        // some code
    });
});

This code has been removed and when still using this code, the user will see an error message in the ADM that the code fails.

If you want to feel more confident, you can perform a full text search in the Objects folder and search for jQuery, $( and $fw(.

BAM Windows Service

In previous releases the BAM Windows service had some database maintenance features built in. Those features are removed because they only applied to the BAM database, and they have been replaced by a full chapter about database and performance maintenance: SQL Server Performance which applies to all databases.

Any maintenance configuration left in the appsettings.json file will have no breaking effect. It will simply be ignored by the BAM service.

Changed Functionality

Jobs to Database

We’ve reworked the scheduling of method jobs and synchronizations to exclusively use the database rather than XML files. Starting from this version, jobs will only be scheduled if they are available in the database. During the upgrade, the patcher will check for any issues with the current method jobs, synchronizations, or schedules and report these as errors.

Invalid jobs will be highlighted in bright red within the business connector. Common causes for invalid jobs include references to renamed objects, methods, or views. These issues can be resolved individually by fixing the configuration and saving the job in the business connector, where any further issue will be displayed during the save action.

This change was made to prevent job configuration corruption due to disk space issues and to avoid scheduling jobs that would immediately result in errors.

Employees, Users and Persons

The links between the dbo.Employees (commonly for case management) and the ident.Users & ident.Persons (for framework authentication) are reworked. In previous versions, the tables are linked at runtime using the available claims from the current user. This was a common cause of confusion when the name or email weren't set in the Employee table, possibly leading to missing case permissions.

Now, both case management and framework authentication will work with the same data without runtime matching. Memberships, case messages and tasks are now granted to Persons which will directly corresponds to the logged in user.

Existing data will be automatically migrated upon upgrading. The process will follow this flow:

• The Users and Employee tables are backed up to UsersBackup and EmployeeBackup.
• [ident].[Users] are linked to [dbo].[Employees] first by Email, then by DisplayName and lastly by UserName.
• Unlinked employees (for example groups) will be kept as is. No employees will be removed.
• A person will be created for each employee (if not already found on the linked user).
• Case memberships and messages are linked to the Person instead of the Employee.
• The employee table is renamed to [ident].[Users].

Jobs and synchronizations should now target the ident.Persons table to create a record for each person or group; the VW_Employees view and DCS.Membership object were modified to adopt this change. Verify if the user synchronization uses these components, or correct the synchronization otherwise.

When users authenticate against the Ometa authority service, they will be automatically linked to this person by their email or name. Since the memberships are now directly linked to a person, there is no ambiguity to which cases are accessible.

The IsGroup functionality for Employees is maintained, these groups will now be represented as Persons in the same manner as other employees. As a refresher, persons are linked to a group if they have a user with the name as adgroup or adgroup.id claim. The Persons & Users window in the Ometa Business Connector will now show the groups and their members to reflect this.

Deprecations

View Formatters for Dates and Numbers

We are planning to make a significant update to the view field formatters used for presenting dates and numbers in a specific format. Going forward, these formatters cannot be used as they were before. Instead, the UI culture setting can now only be configured at the highest level within the config table.

Reason for the Change: Previously, allowing individual views to set their own date and number formats could lead to inconsistencies across different portals. For example, some views were using the format YYYY-MM-DD, while others were using DD/MM/YYYY. To ensure consistency, we have elevated this setting to the highest level.

Impact: By making this change, all dates and number fields will now use the same consistent formatter. This ensures a uniform presentation across the entire application.

Default Setting: The default value for this setting is CurrentUICulture. This means that we consider the current web browser language or, when using SharePoint, the SharePoint language, and apply the corresponding formatter.

This setting will be applied in the next major release.

CSL.multiRecord.getPageData

The CSL.multiRecord.getPageData is set as deprecated. This returned the definitions of the row, instead of just the data.

To get the data, use CSL.multiRecord.getPageRows instead.

View Field Width

The width (and height) settings for inches and centimeters on a create and update views and context managers are made deprecated and should no longer be used.

The reason behind this change is that we follow the advice of the W3C stating that only em, px, and % should be used on screens.

Context With 'caseproperty.' prefix

To prevent conflicts with case properties and other context fields, the case property fields starting with the prefix 'caseproperty.' will no longer be present in the context of a method. You'll have to use the prefix 'case.properties.' or 'originatingcase.properties.' to target (originating) case properties.

CaseId Context Field

The context field named CaseId will be removed in the future. This field currently holds the value of case.id. However, there are scenarios where you might need to overwrite this field in dashboard portals when fetching data across cases. At present, there is no way to do this. We understand that this change could have a significant impact, so we will provide tools to minimize the amount of manual work required.

If you want to have the ID of the case, you must use the provided context field case.id.

Preserved Function Names

Some function names are preserved by Ometa to ensure correct behavior on these functions. In versions before 6.0.0 there could be a ambiguous call to one of those preserved names (e.g. 'Edit'). This name could be used to target the preserved function or the user created one. To ensure that targeting the right function, Ometa updated the preserved function names with '$$obiz'. This way a user can target the correct function.

Preserved name	Target
$$obiz-New	Creation view
$$obiz-Edit	Update view
$$obiz-Update	Update view
$$obiz-InlineEdit	Inline edit function
$$obiz-Details	Single Record view
$$obiz-Refresh	Refresh function
$$obiz-Export	Export function
$$obiz-ContextSetter	Context Setter function
$$obiz-AuditTrailDetails	Audit Trail view

Record Context in Case Type Properties

This outlines the procedure for removing historical "Record Context" data from the [dbo].[CaseTypeProperties] table. We are discontinuing the storage of the full record context for each case creation. This data, found in CaseTypeProperties where the Name column starts with 'Record Context%', represents the full context of the method that created the case. Historically, this was used for legacy BCSP events (e.g., 'BeginCreateSite', 'SiteCreated'). These events have been removed, but the associated record context data remains.

Pre-Deletion Check: Count Records

Before proceeding with the deletion, it's crucial to estimate the number of records to be removed. Run the following query to count the records:

SELECT COUNT(*)
FROM [dbo].[CaseTypeProperties]
WHERE [Name] LIKE 'Record Context%';

If the record count exceeds 2 million, it is imperative to follow the steps below regarding the database recovery model and disk space. If the query returns more than 2 million rows, you must discuss this deletion plan with your Database Administrator. Large deletions can have significant impacts on database performance, transaction log growth, and overall system health. Your DBA can provide valuable guidance on the best approach, scheduling, and necessary precautions for your specific environment.

Set Recovery Model to SIMPLE

Warning: Before deleting a large number of rows, you must set the database recovery model to SIMPLE. This is essential to minimize transaction log growth and prevent potential issues during the deletion process. Failure to do so could lead to the transaction log filling up.

Also, ensure you have sufficient free disk space on the drive where the database data and log files are located. You can check disk space using operating system tools or SQL Server Management Studio (SSMS).

Deletion Procedure

The following SQL script will remove the "Record Context" data in batches of 1000 rows. This batched approach helps manage transaction log size and reduces the impact on database performance.

WHILE (1=1)
BEGIN
    DELETE TOP (1000) FROM [dbo].[CaseTypeProperties]
    WHERE [Name] LIKE 'Record Context%';

    IF @@ROWCOUNT = 0
        BREAK;
END

What's New?

Introducing the Next Step in Our Evolution: The Obiz Suite

We are thrilled to share the latest milestone in our evolution! As we embrace a new web-based experience, we are bringing all web functionalities together under one umbrella: the Obiz Suite. This suite will encompass a trio of applications designed to streamline your workflow:

• Case Management Dashboard: Your centralized hub for tracking and managing cases efficiently.
• Business Activity Monitoring Portal: A real-time window into your business operations.
• Ometa Nexus: Meet the newest addition to our toolkit, the Ometa Nexus, which complements our well-established Ometa Business Connector. The Nexus serves as your intuitive web-based platform for configuring portals and crafting solutions with ease.

The Ometa Nexus debuts with modern forms and a simplified process for managing language labels, setting the stage for a more refined user experience. We'll still support the Ometa Business Connector, but we are gradually migrating all functionality of this server application, to a web based application.

Keep an eye out for further enhancements as we continue to refine the Obiz Suite and Ometa Nexus, ensuring a seamless and productive experience for all users.

ADM

Header Styling

When using modern forms, the header styles are updated to a more modern style. If you would like to apply the legacy styles, you can do so by overwriting the custom obiz theme stylesheet.

Custom Renderer

It is possible to configure a custom renderer on a single record view.

CSL Functions

Translations

There is a new CSL function to work with custom translations in a custom renderer. Refer to the translations article for more information

CSL.translate('myProject.orderTitle')

Clear Context Values

There is a new CSL function to remove the context setter values for the specified component.

CSL.contextManager.clearContextSetter();

Get URL Context

There is a new CSL function to get the full URL context.

CSL.contextManager.getFullContext();

Date Time Conditions

The styling conditions have been extended with new configuration options for datetime fields. You can now use the now and today options to apply custom styling. For instance, you can style expired entries with a red background color.

Building Blocks

The following changes have been made to the building blocks:

• It is possible to create copies of a Ometa Building Block.
• The Ensure File has a new field, Maximum File Size, to check the maximum file size. This limit can be used to block large media files when this building block is used in a frontend application.
• The Ensure List has a new field, Hidden; whether the list is shown in the site contents of the site.

List Internal Name Behaviour

Lists are now retrieved by the internal name before the title for all building blocks. Before this version the List property would only search for the title or GUID of the list on building blocks for fields, views, content type,..

The following behaviour is now used for the List field:

• Retrieve by list ID if the given value is a GUID
• Retrieve by internal name if a list could not be found for the ID
• Retrieve by title if the list could not be found with the title or ID

Easy ADM Selection

For the comfort of the Ometa Business Connector configurators, the Ensure ADM building block has dropdown support for the object and view selection.

Interfaces

AD Interface

The AD interface has been extended with two new operations:

• Rename users
• Move users

Refer to the article for more information.

OData and REST Interface

A new error property could be set holding the error messages of the response. Take the following example where the error message is in the message JSON key.

Set the ErrorMessageSelector to error/message to retrieve the error: Unsupported functionality.

{
  "error": {
    "code": "err123",
    "message": "Unsupported functionality",
    "target": "query",
    "innererror": {
      "trace": "",
      "context": ""
    }
  }
}

Refer to the following articles:

• OData Template
• REST Template

OData Interface

**@odata.nextLink**

The OData interface has support for the @odata.nextLink. This is returned by the OData service when sending too much data in a response.

Query Options

All query options (filtering and sorting) were automatically mapped to the corresponding OData equivalent, even when the OData service did not support it resulting in errors.

It is now possible the process these query options locally (on the Ometa server). Refer to the article for more information.

Web Service Interface

Request Encoding

The encoding used for sending the request to a web service can be configured. Set the Request Encoding field on the web service profile.

Refer to the article for more information.

WSS Certificate

It is now possible to use a certificate to sign the SOAP message. Set the WSS Certificate field on the web service profile.

Refer to the article for more information.

SAP Interface

The performance on large BAPIs with a lot of tables and fields have been improved. We took a mocked BAPI with had 15 tables, with 50 fields and 3000 records. Below we share the results before and after the fix.

Test Case	Speed Before	Speed After
Method with 1 field per table (15 fields)	4,7 seconds	1,22 seconds
Method with 3 fields per table (45 fields)	11,9 seconds	1,48 seconds
Method with 10 fields per table (150 fields)	38 seconds	2,58 seconds

Obiz Suite - Modern Forms

The Modern Forms have been extended to make nested columns.

Ometa Business Connector

View Field Security

It is now possible to configure security on view fields. Users which do not meet the conditions, won't have access to the field's data and the column will not be shown in the ADM.

Check this article for more information.

Config Entry 'Skip Security Checks For Admins'

You can now create/edit the config entry with the name 'Skip Security Checks For Admins'.

If you set this to 'false', admins will also have to pass security checks for authorization policies. This makes it easier for configurators to test their security changes.

If this settings does not exist or has another value than 'false', an admin will always ignore security checks.

Note

This setting does not have any effect on the login proces in the WpfGUI. An administrator will always be able to login to the configuration tool.

Allowed Collection Fieldnames To Csv

A new configuration has been added to support collection values as strings.

Some fields are able to hold a collection of values. Most of the time, these are auto generated fields like identity.emails, identity.groups, case.roles, ...

You can safely use these collection fields in condition sets. Each value in the collection will be interpreted by the condition.

However if you use this field in places where collections are not supported out of the box (e.g.: interface scripts, conversion scripts, validation scripts, custom dll code, ...), only the last value of the collection will be present in that field.

A solution for this issue is to add the name of that collection field in the configuration table under the key Allowed Collection Fieldnames To Csv. If you do this, a new field with the same name suffixed by .csv will be created with all the collection values separated by a comma. See Configuration Table for more information.

Refer to the article for more information.

Rework Security View Function / Multi View / Views Enabled

The configuration of security on view functions, multi view and views enabled (Creation / Update / Single Record View) was reworked to more clearly indicate what is happening. In previous versions, it was shown as Security while in reality it only configures if the multi view or function is available, disabled or hidden in ADM. The security of the underlying target was unchanged. The setting will now be shown as Visibility Conditions in the Business Connector to more accurately reflect this.

In addition, inheriting the policy for a view function meant reusing the policy of the owner (= the multi record that is showing the function). This wasn't very useful because you had to be authorized to see the view in the first place, before being able to click a view function. The inheritance will now refer to the security policy of the target view (or possibly method for functions).

The changed components are:

• Functions tab
  • View Functions (target Method or View)
  • Context Manager Functions
• Views tab
  • Single Record View Enabled
  • Creation Enabled
  • Update Enabled
  • Multiview

The table below shows the scenarios where functions (and others) are available or not:

Setting	Unauthorized Action	Inherited policy	Override policy evaluates success	Authorized to target view	Result: Multiview tab is clickable (Old)	Result: Multiview tab is clickable (New)
Multi View / Functions / Views Enabled	Disable		/
Multi View / Functions / Views Enabled	Disable
Multi View / Functions / Views Enabled	Disable		/		, will show auth error when clicked
Multi View / Functions / Views Enabled	Disable				, will show auth error when clicked	, will show auth error when clicked
Multi View / Functions / Views Enabled	Disable

In short, there is only a difference when using an inherited policy where the user is not authorized to execute the target view. After the upgrade, the function or multi view would become disabled, whereas it would show an authorization error when clicked before.

Small UI Improvements

Various UI changes have been implemented.