Hello everyone,

In this sprint, we have added new ways for clients to specify values for lookup columns and columns with elements when directly POSTing/PATCHing to table, task, and report endpoints.

Note that we have also made a possible breaking change to how the OAuth server scope is applied. Please check the breaking changes section for more information.

You can read more about Indicium's features in the Indicium user manual.

About Indicium

Two types of the Thinkwise Indicium Application Tier are available:

• Indicium Basic: for use with the Windows GUI and Mobile GUI. This basic version does not support features such as system flows and OpenID.

• Indicium: for use with the Universal GUI and via APIs. This version uses the full range of Indicium functionality. Download Indicium release 2024.1.11 here.

Contents

Breaking

OAuth server scope now applies to OAuth server login connector

change

The OAuth server login process flow connector did not use the Scope setting of the corresponding OAuth server configuration when the scope input parameter was not assigned. This has been fixed.

In addition, we have made a minor change to the OAuth user login connector. If this connector had an assignment for the Scope input parameter, but the value of the assignment was empty, it would erroneously fall back to the Scope setting of the OAuth server configuration. This should not happen because the existence of any assignment to the Scope input parameter should always lead to ignoring the Scope setting of the OAuth server configuration.

As of this release, any assignment to the Scope input parameters for the OAuth server login and OAuth user login connectors takes precedence over the Scope setting for the OAuth server configuration. So, even if the input parameter is assigned to a process variable with no value, the OAuth server configuration scope will be ignored. However, if the input parameter is not assigned at all, the OAuth server configuration scope will be used instead in both cases.

Note that both fixes have a small possibility of being a breaking change.

For the OAuth server login connector, this change can be breaking when both of the following conditions are met:

• The OAuth server login connector has no assignment for the Scope input parameter.
• The corresponding OAuth server does have a Scope configured.

In this case, Indicium would previously not send a scope to the OAuth provider, but as of this release, it will send the scope defined in the OAuth server configuration.

For the OAuth user login connector, this change can be breaking when both of the following conditions are met:

• The OAuth user login connector is assigned to a process variable, and the value of this process variable may be empty.
• The corresponding OAuth server has a Scope configured.

In this case, Indicium would previously send the scope defined in the OAuth server configuration to the OAuth provider, but as of this release, no scope will be sent.

New and changed

Added ways to choose

new

We have added new ways for clients to specify values for lookup columns and columns with elements when directly POSTing/PATCHing to table, task, and report endpoints.

The first one is choose. Use it to choose a lookup value by providing the primary key values of the lookup source. This can be useful if the client knows from which source record to select the target value, but the foreign key from the target to the source is not part of the source's primary key.

POST <metasource>/<application>/<target_table>
{
  "<target_FK_column>": {
    "choose": {
      "<source_PK_column>": "36724a01-521a-4b4a-b51f-30d943f9a0d0"
    }
  }
}

The second one is choose_by_display. You can use it to choose a lookup value by providing the value from the column configured as the display column.

For example, if the model contains a project table:

And a sub_project table that has a sub_project.project_id -> project.project_id lookup which is configured to display the project.project_name. Then Indicium allows the following when adding a new sub_project:

POST <metasource>/<application>/sub_project

{
  "project_id": {
    "choose_by_display": {
      "display_value": "Example project"
    }
  }
}

Which, in the example above, would resolve to 1234 as the value for project_id for the new subproject.

The third way is the choose_by_element translation. Use it to choose the database value for a column configured with elements based on the translation value of an element.

For example, in a model containing a domain example_domain configured with the following elements:

And element translations:

Then Indicium will allow a column using this domain to be posted or patched like this:

POST <metasource>/<application>/example_table
{
  "some_element_column": {
    "choose_by_element": {
      "element_transl": "Element two"
    }
  }
}

PATCH <metasource>/<application>/example_table(1234)
{
  "some_element_column": {
    "choose_by_element": {
      "element_transl": "Element three"
    }
  }
}

By default, this feature uses the session user's language to match the translations or the application's fallback language if the application does not contain translations for the user language. The above example assumes this to be English (EN) for the user making the example request. You can overwrite this behavior by providing a language_hint value with the column. For example, to use Dutch instead of English in the previous example, specify the following:

POST <metasource>/<application>/example_table
{
  "some_element_column": {
    "choose_by_element": {
      "element_transl": "Element twee",
      "language_hint": "NL"
    }
  }
}

If the language for the language_hint cannot be found, the application's fallback language will be used instead.

Minor fixes and tasks

• When shutting down or restarting, Indicium attempts to wait for all running system flows to finish before ending the process. Although this functioned correctly, it sometimes generated error messages in the error log. This issue has been resolved.

Questions or suggestions?