Released: Q3 2024

Get ready for the highly anticipated Reisalpe release! This iteration of Portrait, the critically acclaimed platform, takes innovation to the next level with powerful new features and mighty enhancements, empowering your enterprise like never before. Discover the future of enterprise apps today!

Before we start, we invite you to check all those features we shipped since our last major-release:

• Portrait 6.1.0 - Schöpfl - Scripting support, Boolean fields, Hot Reload Configuration,…

• Portrait 6.2.0 - Schöpfl - Forms 2.0: Value Sliders, Entry Fields, Postprocessing for ELO, etc…

• Portrait 6.3.0 - Schöpfl - Modal forms, password fields, group timeline entries,…

• Portrait 6.4.0 - Schöpfl - Push Notifications, list view on mobile, optimized config hot reload,…

• Portrait 6.5.0 - Schöpfl - Field processors math operators, user view,…

• Portrait 6.6.0 - Schöpfl - Document Scanner, Revamped map view,…

Obviously, Schöpfl was a feature-packed iteration and made digitalization for our customers a lot easier and intuitive. With the upbringing of Portrait 7.0 we hat-tip to “Schöpfl”: We thank you for your services and say goodbye to Portrait 6.0. May the retirement be a relaxing one!

Release “Reisalpe” will be the next summit ahead. With the initial release, not only did we work on bugs and security, but we immediately bring in new features.

Highlights

This links seem to be “edit” links!!!

Security improvements notice

At Treskon, we take application security seriously, which is why we continuously enhance the security features of our platform. We strive to strike a balance between automated configuration options and strict input validation, ensuring that our users can build flexible and dynamic web applications with confidence.

Please note that Portrait is designed to empower admins to create custom web applications. While we prioritize robust security, we also recognize the importance of flexibility and ease of use in our platform. As such, you may need to perform manual configuration or make informed decisions about trade-offs between security and functionality.

As an admin using Portrait to build your application, it's essential that you consider your own application's security needs and take responsibility for ensuring its security. With our latest update, we're introducing new configuration options that enable admins like you to further strengthen their application's security by adding custom input validation, permissions, conditions, and limiting form submissions to specific entries. These enhancements empower you to build applications that meet your unique needs while maintaining a high level of security.

Permissions

Sections can now be configured to be only accessible for admins.

- name: src-inventory
  role: ADMIN
  caption: Inventory

Admin only sections will now be displayed in the administration view:

Actions 2.0

The Action inside a Section has been reworked and now support

• conditional expression. see https://portrait.atlassian.net/wiki/spaces/PA7/pages/1029117068/Draft+7.0.0+-+Reisalpe#Conditions

• Handlebar Support for Labels and Links.

• Support to link multiple Forms within a single Section Entry

Actions for Links

Example:

- name: vacations
  group: Demo
  caption: Vacations
  type: list
  description: |
    Übersicht der Urlaube
  formId: create_vacation
  icon: 'edit'
  actions:
    - label: 'Edit vacation' # Handlebar
      key: 'edit_vacation'
      type: 'FORM' # [LINK, FORM ]
      condition:
        - expression: "{{eq VACATION_EMAIL PORTRAIT_USER_EMAIL}}"
      forwardFields:
        - key
        - VACATION_EMAIL
        - VACATION_DATE
        - VACATION_STATUS

So all Entries of src-inventory have the same configured actions available. However not all actions are displayed equally. For example inventory items that are not in stock (amount <= 0) the link is not displayed. In addition, the value of the link is also different for each inventory item

Actions for triggering Forms

I am logged in as user linda.jackson and therfore are only allowed to open the edit vacation form assigned to this user.

Example

actions:
  - label: 'Edit vacation' # Handlebar
    key: 'action1'
    value: 'create_vacation'
    type: 'FORM' # [LINK, FORM ]
    condition:
      - expression: "{{eq VACATION_EMAIL PORTRAIT_USER_EMAIL}}"
    forwardFields:
      - key
      - VACATION_EMAIL
      - VACATION_DATE
      - VACATION_STATUS

Details, see: Actions

Forms

Permissions

Forms can now be configured to be only accessible for admins.

- id: createInventoryItem
  role: ADMIN
  onSubmit:
    type: ELO
    ...
  dialog: config/forms/createInventoryItem.json

Field processor

Field Processors support has been extended and is now available for

• ELO

• Python

• SQL

They work similar to the Field Processors in ELO.

Python

The evaluated Field processors are passed alongside the form fields to the python script via the --args flag.

SQL

The evaluated Field processors are available as variables for the SQL query.

Forms based on existing entries - Mode and Scope

It is now possible to link forms to existing entries. This allows Portrait administrators to further increase their application security and data consistency. To achieve this goal, we introduced multiple configuration options.

Update-Mode

With the new Mode Update you make the ‘previous’ entry-fields available as variables to be used for Field Processors, SQL queries or further processing in your Python script. In other words, the Create-Mode ignores existing entries - and therefore shouldn’t be used if you need conditions or security.

Overview of the currently supported modes:

Strict-Scope (ELO only)

Furthermore the scope setting was introduced. This was necessary, since it was possible in Portrait 6.x to manipulate unrelated Sord’s in ELO with some “bad-actor-energy”. We won’t go into details here.

However, with Portrait 7.x things changed with the setting the scope to Strict. This will prevent editing unrelated Sord's which are not indexed in Portrait.

Therefore, it is highly recommended to apply this configuration.

Summary

Still unsure, what to do? We got your back:

If you have forms, that submit data to ELO, add the mode property to the onSubmit settings and set it accordingly. It will be either: CREATE, UPDATE or DELETE. Also set the scope to STRICT.

If you have forms, that submit data to SQL or Python, add the mode property to the onSubmit settings and set it accordingly. It will be either: CREATE or UPDATE.

Please read our docs on the given use-case, wholeheartedly:

• Post Processing (onSubmit) - In general, no matter the destination.

• ELO - use the form data in ELO. You will find a separate chapter about the improved security considerations.

• SQL - use the form data in SQL prepared statements.

• Python - use the form data in python scripts.

• BLP 5.1 - start ELO BLP processes.

Examples

This examples shall round up the previous:

ELO - Update an entry

You have a form in Portrait, that should edit an indexed entry in Portrait and ELO. The config:

- id: edit_entry_withELO
  onSubmit:
    mode: UPDATE
    source: sectionID
    scope: STRICT
    ...

ELO - Delete an entry

Three configs are required:

- id: delete_entry
  onSubmit:
    mode: DELETE
    source: sectionID
    scope: STRICT
    ...

Python/SQL - Update an entry

Two configs are required:

• mode: UPDATE

• source: sectionID

• forward ‘key’ in the section action config. https://portrait.atlassian.net/wiki/spaces/PA7/pages/1029113865/Column+Types#Form

- id: edit_entry_
  onSubmit:
    type: SQL
    mode: UPDATE
    source: sectionID
    ...

BLP5.1 - Trigger a process

These configs are required:

- id: edit_entry_with_BLP51
  onSubmit:
    type: BLP5.1
    ....
  

The attributes are prefixed with ORIGIN_ (STATUS → ORIGIN_STATUS)

In addition a security check is applied:

• If no entry is found for the configured section and key the form submit is canceled with an error.

Python/SQL

Two configs are required:

• mode: UPDATE

• source: sectionID

• forward ‘key’ in the section action config. https://portrait.atlassian.net/wiki/spaces/PA7/pages/1029113865/Column+Types#Form

- id: edit_entry
  onSubmit:
    mode: UPDATE
    source: sectionID

ELO

Three configs are required:

- id: edit_entry
  onSubmit:
    mode: UPDATE
    source: sectionID
    scope: STRICT

Scope (Strict / Loose)

A parameter scope has been added to the onSubmitconfiguration element.
This can either be STRICT or LOOSE

- id: create_vacation
  onSubmit:
    type: ELO
    ...
    source: vacations
    scope: STRICT

STRICT:

Please set all ELO mask attributes explicitly via FieldProcessors, see: https://portrait.atlassian.net/wiki/spaces/PA7/pages/1029112687/ELO#Mask-Attributes

For mode Update/Delete there are additional requirements and checks:

Required config for mode UPDATE/DELETE:

• The source: <sectionID> parameter needs to be set → this is the sectionID of the referenced section

For more details on the purpose and effect of the strict mode see:

https://portrait.atlassian.net/wiki/spaces/PA7/pages/1029112687/ELO#Improved-Security%3A-Scope-(Strict-%2F-Loose)

Conditions

With Portrait 7.0 we introduce the concept of conditions, which allows for extensive input validation to keep your data consistent at all times.

Furthermore, you can define which user can use which operation. Like this you can enforce “ACL” / permissions and define, which user is allowed to edit or delete an entry. I´

A condition is a boolean expression when evaluated either allow or prevent:

• Section actions: https://portrait.atlassian.net/wiki/x/AQBwPQ - conditional serving of user actions, based on the metadata.

• Form submit: https://portrait.atlassian.net/wiki/spaces/PA7/pages/1029112649/Post+Processing+onSubmit#Conditions - conditional validation of a form submit on the backend.

Example

condition:
  - expression: "{{in SELECTED_STATUS 'STATUS1' 'STATUS2'}}"
    errorMessage: 'only STATUS1 or STATUS2 are allowed'
  - expression: "{{in SELECTED_EMAIL PORTRAIT_USER_EMAIL}}"
    errorMessage: 'you can only edit your own entries'

Multiple conditions can be set. All conditions need to match. (Logical AND between all conditions). You can build more complex rules with nested handlebars.

- expression: "{{or (in SELECTED_STATUS 'STATUS1' 'STATUS2') (eq PORTRAIT_USER_ROLE 'ADMIN')}}"
  errorMessage: 'only STATUS1 or STATUS2 are allowed, Admin can do anything.'

If needed, variables can also be preprocessed with Field Processors, this allows a better readability.

 - id: edit_entry
      onSubmit:
        type: ELO
        connection: eloconn
        mask: ELOMASK
        mode: UPDATE
        source: eloSource
        scope: STRICT
        condition:
          - expression: "{{or IS_VALID_STATUS IS_ADMIN_USER}}"
            errorMessage: 'only STATUS1 or STATUS2 are allowed, Admin can do anything'
        fieldProcessor:
          - field: STATUS
            value: "{{SELECTED_STATUS}}"
          - field: IS_VALID_STATUS
            value: "{{in SELECTED_STATUS 'STATUS1' 'STATUS2'}}"
            type: BOOLEAN
          - field: IS_ADMIN_USER
            value: "{{eq PORTRAIT_USER_ROLE 'ADMIN'}}"
            type: BOOLEAN

Conditional support on forms https://portrait.atlassian.net/wiki/x/SQNXPQ currently works for:

• ELO

• Python

• SQL

For more details, see: https://portrait.atlassian.net/wiki/x/AYDHPg

Section actions

The action inside a section has been reworked and now support:

• Conditional expressions: These allow to write custom boolean expression to either display or hide a action based on the metadata.

• Handlebar Support for Labels and Links.

• Support to link multiple Forms within a single section entry

Details, see: Actions

Field processor

Field processors are a powerful tool to manipulate and evaluate data. Field processors are integrated in several areas of Portrait. Use them inside Sources to add or modify a field while reindexing data, use them within a form submit to validate the posted data, add them to actions to have conditional visibility of actions.

In this release we added new functionality to the field processors.

Boolean

A new type boolean has been added.

Example

 fieldProcessor:
        - field: BudgetLeft
          value: '{{gt Amount 0}}'
          type: BOOLEAN

Details, see: Field Processors

In Helper

Check if a given value is contained in a given list of other values:

{{in SELECT_VACATION_STATUS 'GENEHMIGT' 'ABGELEHNT'}}

Also a combination with various split methods is possible:

{{in PORTRAIT_USER_EMAIL (splitBySemicolon EVENT_PARTICIPANTS) 'admin@portrait.com'}}

Details, see: https://portrait.atlassian.net/wiki/spaces/PA7/pages/1029114243/Field+Processors#In

File download

It is now possible to download files linked to an indexed ELO entry directly from the table or detail view.

Example

sourceSpecific:
  mask: Application Entry
  files:
    nesting: 1
    mask: Application Attachment

Will be displayed like this:

Depending on the file type, a preview is available. All files are available to download.

Search index space optimization

We optimized the required disk space for the search recommendations. To take full advantage of this, we recommend that you delete your index and rebuild them from scratch.

To do this:

1. Delete your sources that you want to optimize in the admin dashboard.
   

   

2. Restart Portrait

3. If mandatory, trigger a manual reindex if not configured periodic reindexing.

Breaking changes

Breaking changes led to a major release. In this chapter, we summarize the breaking changes - which might affect your installation and need to be considered, whilst upgrading.

SQL form submit parameter

We increased the security measurements whilst dealing with SQL write operations. This means, the SQL query will be parsed as prepared statement. For safety reasons, we enforce this style now for every SQL query. These changed are valid for all DML Statements. DDL Statements are not supported anymore.

Example

Given this example for the createNewCompany form:

In this given example, the form-data will be inserted into the table DemoOrganigram via the connection organigram.

The FieldProcessors can either be used to format fields or as a fallback in case of an optional field in the form. If not supplied the Query would fail as there would be no valid parameter :Name if not set previously. With the given FieldProcessor the fallback is an empty string.

Details, see: https://portrait.atlassian.net/wiki/x/pQNXPQ

ELO sources files indexing

When indexing files to the public folder, it is now required to set publicCache: true.

Example

sourceSpecific:
  mask: Application Entry
  files:
    publicCache: true
    nesting: 1
    mask: Application Attachment

Details, see: https://portrait.atlassian.net/wiki/spaces/PA7/pages/1029114146/ELO+sources#Index-Documents%2FFiles

Indexed files are also displayed in the section view and are available as a download.
Optionally, this behaviour can be disabled by setting the following flag inside the section:

- name: sectionid
  disableFiles: true

Details, see: Settings

ELO sources Adminbase and Chaosablage indexing

When indexing elements within the ELO Administration (aka. “Administration” folder) and “Chaosablage”, results are per default now ignored this can be changed with:

sourceSpecific:
        blacklistChaosablage: false #default, if not set: true
        blacklistAdministration: false #default, if not set: true 

In addition you can also provide own folder GUIDs that will be excluded.

Details, see: ELO sources

ELO source-ID's

With this version, we switch to a more classic approach, like how ELO uses GUID’s. In ELO the identifier for a SORD is either a Object-Id, or a GUID. We use the GUID of ELO, but previously we removed the surrounding brackets artificially. With Release 7.X we remove this artificially modification of the GUID:

There might be some changes required in your configuration, when you used Field Processors, that use or manipulate the ELO-GUID’s.

Examples

This examples prove, that with the new, unaltered, approach, the configuration gets simplier.

API changes

We did our homework, and the API, especially the documentation for it, is now concise and this will increase the possibilites to better integrate Portrait in your automations. If you open the API docs you will find a clean and grouped doc.

We also changed the following API routes, for better clarity: