Released: Q3 28 Aug 2024

Highlights Portrait - 7.0.0

Forms based on existing Entries

Elasticsearch Index Space Optimization

Field Processor - new Helper and Types

Security Improvements Notice

At Portrait, we take application security extremely 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.

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

role String

ADMIN = only admins can see this section

USER = every user can see this data

If you don’t define it, role USER will be applied

Admin only sections will be displayed in the administration view.

Image Removed

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

Insert excerptActionsActionsnameactions marketingnopaneltrue

Details, see: Actions

Forms

Permissions

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

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

role String

ADMIN = only admins can see this section

USER = every user can see this data

If you don’t define it, role USER will be applied

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

Excerpt

name	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:

Mode Update (new for SQL and Python)

SubmitType	ELO	SQL	Python	BLP 5.1
Supported

With the Mode Update you can get the ‘previous’ attributes from an entry available as variables to be used for Field Processors, SQL Query or further processing in your Python script.

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

Python/SQL

Two configs are required:

mode: UPDATE

source: sectionID

forward ‘key’ in the section action config.

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 processor 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.

In the spirit of our versioning scheme, minor-releases in the 7.x series will also bring new features a long the way. Remember: Major releases mainly indicate that breaking changes are occurring.

Highlights

Section Actions

Forms based on existing entries

Section Permissions

Form Permissions

Conditions - Input validation

File Download and Preview

API changes

References

Elasticsearch index space optimization

Field Processor - new Helper and Types

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.

Code Block
- name: hr role: ADMIN caption: HR group: Management

role String

ADMIN = only admins can see this section

USER = every user can see this data

If you don’t define it, role USER will be applied

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

Image Added

Section Actions

The Action inside a Section has been reworked and now support:

Conditional expression. See: https://portrait.atlassian.net/wiki/spaces/PA7/pages/

1029113865/Column+Types#Form

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

ELO:

Three configs are required:

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

Scope (Strict / Loose)

SubmitType	ELO	SQL	Python	BLP 5.1
Supported

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

Code Block- id: create_vacation onSubmit: type: ELO

1029117068/Portrait+7.0.0+-+Reisalpe#Conditions
Handlebar Support for Labels and Links.
Use multiple Forms within a single section entry

This will be useful, if you need to allow an action/form only if a certain criteria is met.

Example

Imagine, Portrait is used to manage the inventory of field-service-engineers. Portrait has an overview of each service-engineers personal inventory. Therefore, Portrait, lists the current stock of the inventory.

In case an inventory item is low, the service-engineer shall be able to file a restock form. So, only if the stock is sub 3 items, the form restockItemForm shall be shown to the user:

Config inside the section inventory:

Code Block

sections:
  section:
    - name: inventory
      ...

source

actions:

vacations

scope: STRICT

STRICT:

Info
The STRICT Scope is meant to protect your ELO Instance from being manipulated in ways that you did not configured in the first place: Like editing unrelated Sords which are not indexed. Therefore it is highly recommended to apply this configuration.

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.

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

Section Actions https://portrait.atlassian.net/wiki/x/AQBwPQ
Form submit (backend validated) https://portrait.atlassian.net/wiki/spaces/PA7/pages/1029112649/Post+Processing+onSubmit#Conditions

Example:

Code Block

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.

Code Block
- 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 fieldProcessors, this allows for a better readability.

Code Block

 - 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 Currently 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 expression. These allow to write custom boolean expression to either display or hide a action on an entry to entry base.
Handlebar Support for Labels and Links.
Support to link multiple Forms within a single Section Entry

Details, see: Actions

Field Processor

Type Boolean

A new type boolean has been added. Example:

 fieldProcessor:
        - field: BudgetLeftlabel: 'Order Restock'
          key: 'restockItemAction'
          type: 'FORM'
          condition:
            - expression: '{{lt Amount 3}}'
          value: 'restockItemForm'
          icon: 'shopping-bag'

This will show the button to open the form restockItemForm, because Amount is lower than 3:

Image Added

Details, see: Actions.

Forms

Forms and the underlying onSubmit implementation got a big update:

Permissions

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

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

role String

ADMIN = only admins can see this section

USER = every user can see this data

If you don’t define it, role USER will be applied

Field Processors

Field Processors support has been added to forms and is now also available for: Python, SQL. They work similar to the existing implementation of Field Processors for ELO:

For Python, the evaluated Field Processors are passed alongside the form fields to the python script via the --args flag.
For 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.

Note
Do not confuse the Update-Mode with an SQL UPDATE Statement.

Overview of the currently supported modes:

Submit-Type	ELO	SQL	Python	BLP 5.1
Create-Mode
Update-Mode
Delete-Mode
Default	Create	Create	Create	Create

The Update-Mode also brings you the ability to compare the new form-input with the existing entry data inside the index. The original attributes are therefore prefixed with ORIGIN_ (STATUS → ORIGIN_STATUS). Comes in handy, if you want to use Conditions on form submit.

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.

Note
In the upcoming releases of Portrait, we may will enforce the scope to `STRICT`. Act now, to avoid issues in the future.

Plausibility check

In addition a check is applied:

SQL and Python
- If a form is submitted and no corresponding entry is found in the Portrait index, the operation is cancelled.
ELO
- If a form is submitted and no corresponding entry is found in the Portrait index AND the scope is set the STRICT, the operation is cancelled

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 property 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.

This examples shall round it up:

Example 1: ELO - Update an entry

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

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

Example 2: ELO - Delete an entry

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

Code Block
- id: delete_entry_withELO onSubmit: mode: DELETE source: sectionID scope: STRICT ...

Example 3: Python - Update an entry

You have a form in Portrait, that should edit an indexed entry in Portrait and run a py-script. The config:

Code Block
- id: edit_entry_withPy onSubmit: type: Python mode: UPDATE source: sectionID ...

Example 4: SQL - Update an entry

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

Code Block
- id: edit_entry_withSQL onSubmit: type: SQL mode: UPDATE source: sectionID ...

Example 5: BLP5.1 - Trigger a process

You have a form in Portrait, that should start a process in BLP5.1. The config:

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

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

Code Block

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.

Code Block
- 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.

Code Block

 - 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 and SQL.

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

Field processors

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

Code Block
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:

Code Block
{{in SELECT_VACATION_STATUS 'GENEHMIGT' 'ABGELEHNT'}}

Also a combination with various split methods is possible:

Code Block
{{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

Code Block
sourceSpecific: mask: Service files: nesting: 1 mask: Service Document

Will be displayed like this:

Image Added

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

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

References

A new nifty feature is to reference between entries (across different sections) in Portrait.

Example

Imagine, Portrait is used to manage the incidents for service-engineers. Each service-engineer has a list of incidents. However each incident relates to a facility. Therefore it is useful to link from the incident to the facility, to see all documents, manuals and other details of the facility itself.

Image Added

To achieve this, you need the new column type reference. The Config inside the section “incidents” looks like this:

Code Block

sections:
  section:
    - name: incidents
      ...
      columns:
        - label: 'Facility'
          key: 'ServiceFacilityNo' #contains the key of the target entry
          type: 'reference'
          options:
            value: '{{gt Amount 0}}'sectionID: facilities-at # section where the reference should target
            type: BOOLEAN

Details Field Processors

In Helper

A new type helper has been added.

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

Code Block
{{in SELECT_VACATION_STATUS 'GENEHMIGT' 'ABGELEHNT'}}

Also a combination with various split methods is possible

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

Details: 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.

Configuration

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

Will be displayed like this:

Image Removed

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

Search

Elasticsearch Index Space Optimization

fieldKey:  FAC_NAME # label for the reference, inside the incident section

The value of ServiceFacilityNo is 5001 (per example above) and this must also be the unique identifier for the entry in the facility source.

You can check this, by having a look at the URL of the target entry: https://service.customer.com/facilities-at/5001/

Info
For SQL you need to set the key manually. For ELO sources you can overwrite the unique key in the configuration of your source. Details, see: SQL sources or ELO sources.

Details, see: https://portrait.atlassian.net/wiki/spaces/PA7/pages/1029113865/Column+Types#Reference

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:

Delete your sources that you want to optimize in the admin dashboard.
Restart Portrait
If mandatory, trigger a manual reindex if not configured periodic reindexing.

Breaking

Changes

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

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.

→ achtung bitte nur hier editieren

im verlinkten ists es auch. ich will es mit / insertexcerpt verlinken anstatt alles doppelt zu haben im idealfall. Wenn moeglich halt

ok, dann halte ich mich kurz beim “promoten” der neuen Version.

Dann entfernen wir den Code unterhalb und beschreiben es in der Dok only?

so:

Given the example for the 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:

Old - 6.x

Code Block
- id:

updateCompany

createNewCompany
  onSubmit:
    type: SQL
    connection:

organigram

 internal
    
    
    
    
    
    
    
    
    query: |
      INSERT

UPDATE

INTO DemoOrganigram (Name, PARENT_IDS, PARENT_LABELS)

SET

NAME

=

VALUES ('{{

name

Name}}',

PARENT_LABELS =

 '{{PARENT_

LABELS

IDS}}',

COUNTRY =

'{{

COUNTRY

PARENT_LABELS}}'

, REGION = '{{REGION}}', GF = '{{GF}}', SUB_COMPANIES = '{{SUB_COMPANIES}}' WHERE ID = '{{ID}}';

New Format

Insert excerptSQLSQLnamesql marketingnopaneltrue

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

TODO remove this: New Format

Code Block- id: updateCompany onSubmit: type: SQL mode: UPDATE source: demo-organigram # used to get access to ORIGIN_ID for improved security connection: organigram # the database connection the update statement should run against fieldProcessor: # Useful for optional fields which otherwise could not be set in the SQL statement - field: NAME value: "{{NAME}}" - field: PARENT_LABELS value: "{{PARENT_LABELS}}" - field: COUNTRY value: "{{COUNTRY}}" - field: REGION value: "{{REGION}}" - field: GF value: "{{GF}}" - field: SUB_COMPANIES

);

New - 7.x

Code Block

- id: createNewCompany
  onSubmit:
    type: SQL
    connection: organigram
    source: demo-organigram
    fieldProcessor:
      - field: Name
        value: "{{Name}}"
      - field: PARENT_IDS
        value: "{{PARENT_IDS}}"
      - field: PARENT_LABELS
        value: "{{PARENT_LABELS}}"
    query: |
      INSERT INTO DemoOrganigram (Name, PARENT_IDS, PARENT_LABELS)
        VALUES (:Name, :PARENT_IDS, :PARENT_LABELS);

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.

Info

This is relevant to you, if you use Portrait in public mode - without authentication.

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:

Code Block

sourceSpecific:
         valueblacklistChaosablage: "{{SUB_COMPANIES}}"
    query: |
false #default, if not set: true
     UPDATE DemoOrganigram  blacklistAdministration:      SET NAME = :NAME, PARENT_LABELS = :PARENT_LABELS, COUNTRY = :COUNTRY, REGION = :REGION, GF = :GF, SUB_COMPANIES = :SUB_COMPANIES
      WHERE ID = :ORIGIN_ID;

ELO Sources Files Indexing

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

Info

This is relevant to you, if you use Portrait in public mode - without authentication.

ELO Sources Adminbase and Chaosablage indexing

When indexing Elements within the Administrationbase (“Administration” Folder) and “Chaosablage” results are per default now ignored this can be changed with

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

https://treskon.atlassian.net/browse/POR-871

ELO sources

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

Screenshot 2024-04-25 at 10.33.02.png Image Removed

ELO Sources IDs

With this version we switch to a more classic approach how ELO uses GUIDS. In ELO the identifier for an SORD is in there form of:

Object ID	GUID
17593	(FC4B5EB2-359A-2FAE-C3DE-AC908A1A6BD9)

Previously we removed the surrounding brackets artificially. So the ID inside portrait had been ‘FC4B5EB2-359A-2FAE-C3DE-AC908A1A6BD9’.

With Release 7.X we remove this artificially modification of the GUID.

Note
To maintain a consistent database ,we recommend to clear the existing ELO indexes and reindex them!

There might be some changes required in your configuration when you already used the ELO-GUID directly by the substring handlebar.

Example

Before

After

Code Block
value: '{{#if SHARE_PARENT_ELOGUID}}[Open](https://organigram.tuev.at/complete/{{substring SHARE_PARENT_ELOGUID 1 37 }}/hi){{/if}}'

Code Block
value: '{{#if SHARE_PARENT_ELOGUID}}[Open](https://organigram.tuev.at/complete/{{SHARE_PARENT_ELOGUID}}/hi){{/if}}'

value: 'elodms://({{key}})'

value: 'elodms://{{key}}'

value: '{{substring SHARE_SUBSIDIARY_ELOGUID 1 37 }}'

value: '{{SHARE_SUBSIDIARY_ELOGUID}}'

API changes

The following API routes were removed in this release:

GET DATA / Search:

old URL: /data/{term} and /data

was changed to

new URL: /search/{term} and /search

GET DocDetails:

URL: /docDetails/{docId} (where docID was similar to the entryID)

Desc: This allowed to retrieve the key value pairs for a single entry. Similar to /entries/{sectionID}/{entryID}. However, it

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:

ELO Unique Identifier	Old - 6.x	New - 7.x
GUID	`FC4B5EB2-359A-2FAE-C3DE-AC908A1A6BD9`	`(FC4B5EB2-359A-2FAE-C3DE-AC908A1A6BD9)`

Note
To maintain a consistent database ,we recommend to clear the existing ELO indexes and reindex!

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

Examples

Field Processor Use-Case	Old - 6.x	New - 7.x
A link to another Portrait detail entry. With 6.x you needed a substring manipulation.	`value: '{{#if PARENT_ELOGUID}}[Open](https://organigram.customer.com/complete/{{substring PARENT_ELOGUID 1 37 }}/hi){{/if}}'`	`value: '{{#if PARENT_ELOGUID}}[Open](https://organigram.customer.com/complete/{{PARENT_ELOGUID}}/hi){{/if}}'`
A link to the ELO Rich Client (via ELO protocol handler). In 6.x you had to add `( )` to the link.	`value: 'elodms://({{key}})'`	`value: 'elodms://{{key}}'`
When building references for the organigram inside Portrait, you had to remove the `( )`.	`value: '{{substring SHARE_SUBSIDIARY_ELOGUID 1 37 }}'`	`value: '{{SHARE_SUBSIDIARY_ELOGUID}}'`

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

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 now.

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

API Use-Case

Old - 6.x

New - 7.x

Get all entries for a specific section or the global search

/data/

/search/

Get all entries for specific section or the global search with filter term (search query)

/data/{term}

/search/{term}

Retrieve the key value pairs for a single entry - nonetheless, what section it is in.

/docDetails/{docId}
(where docID was similar to the entryID)

This would lead to an issue when there would be the same entryID in two different sections. To guarantee uniqueness

DocDetails

, docDetails was removed

Alternative:

Use either /entries/{sectionID}/{entryID} to query an unique entry. Or/data/{term} to perform a global search.

GET Sources:

URL:

Method to retrieve a certain entry - via the source.

sources/{index}/{entryID}

Desc: Method to retrieve a certain entry. This was

This is similar to/entries/{sectionID}/{entryID}

.

Alternative:

Use /entries/{sectionID}/{entryID}

Info

INFO:

Currently there is a strong 1:1 connection between source and section. In the

next versions

following, we plan to loosen up this restriction to

connection

connect a single source to multiple sections. This API change is one of the first steps towards that goal.

Page Comparison

Versions Compared

Key

Security Improvements Notice

Permissions

Actions 2.0

Forms

Permissions

Field Processor

Python

SQL

Forms based on existing Entries - Mode and Scope

Mode Update (new for SQL and Python)

Python/SQL

Highlights

Security improvements notice

Permissions

Section Actions

ELO:

Scope (Strict / Loose)

Conditions

Section Actions

Field Processor

Type Boolean

Forms

Permissions

Field Processors

Forms based on existing entries - Mode and Scope

Update-Mode

Strict-Scope (ELO only)

Plausibility check

Summary

Example 1: ELO - Update an entry

Example 2: ELO - Delete an entry

Example 3: Python - Update an entry

Example 4: SQL - Update an entry

Example 5: BLP5.1 - Trigger a process

Conditions

Field processors

Boolean

In Helper

File download

References

In Helper

File Download

Search

Search index space optimization

Breaking

changes

SQL

form submit parameter

New Format

ELO sources files indexing

ELO sources Adminbase and Chaosablage indexing

ELO Sources Files Indexing

ELO Sources Adminbase and Chaosablage indexing

ELO Sources IDs

API changes

GET DATA / Search:

GET DocDetails:

ELO source-ID's

API changes

GET Sources: