Based on custom fields of a user, sections are filtered, so that each user only sees the data meant for him. This is a different concept to typically known “permissions groups” in other applications, since the Custom Fields concepts are basically pre-filtering every search result.

Use case: Sharing documents with customers

The functionality is best explained by going through a typical requirement.

Problem

As a freight forwarding company, you need to document your business. For one thing, you need an audit trail and therefore store your documents internally in a digital form. For another thing, you need to have a proof of delivery towards your contractor.

One proof could be a delivery note paper handed over to the recipient. But you still have to give proof to the sender, which is usually your contractor as well.

Since you already collect delivery notes and digitalize them, you can use this internal data set and share with the sender (your contractor) – or other sparing partners.

But that would mean you need to give access to your internal system to externals and built an additional permission layer – that focuses on externals. That is for once high maintenance and a huge risk factor.

Solution

Therefore, building a separate application with Portrait – on top of the existing data – for externals is the way to go. Next up, you need to make sure to manage which delivery notes can be seen by whom.

This can be done with Custom Fields, because every delivery note is not only a scanned document, but also contains metadata about your recipient, sender, and customer.

You can create Custom Fields for each Portrait user and logically compare them with the fields on each entry and decide therefore if they are allowed to see the entry or not.

Implementation

In our use case, the data is already imported and at first sight we can see that we have 275 delivery notes in our section “2022”. We can already spot at least 3 documents from the same customer, “000115”:

The field, in which the customer number is stored, is called CUSTNR (line 15):

sections:
  section:
    - name: shipping-note-2022
      group: Lieferscheine
      caption: 2022
      description: |
        Alle Lieferscheine aus dem Jahr 2022.
      columns:
        - label: 'Name'
          key: 'name'
          type: 'string'
          showInTableHeader: true
          showInDetailList: false
        - label: 'Kundennumer'
          key: 'CUSTNR'
          type: 'string'
          showInTableHeader: true
          showInDetailList: true
        - label: 'Archivdatum'
          key: 'iDateIso'
          type: 'date'
          showInTableHeader: true
          showInDetailList: true

That means we need to create a Custom Field with the name CUSTNR in the yaml-file:

global-properties:
  customFields:
    CUSTNR: YourDefaultValue

Setting the value to “YourDefaultValue” is a good way to make sure, the custom field is always applied – even if the original value is empty. Since this is about security, we set a default value that we can expect will not yield any result. We could’ve also set “SquareDinosaur”, “XXX” or “NoCustomerNumberGiven”.

Since this field support search terms do not use * as default – it will have the opposite effect.

Restart the backend, go to the user administration and open the user of your customer “000115”.

Set the field CUSTNR to “000115”:

After you saved the settings, the next time the user opens the section the view is already filtered:

And you’re done. ✌️

Synopsis

The Custom Fields are a powerful tool to build apps with the same structure, but at the same time deliver different content based on who is looking at it. Since the permission are always “content based” you can build them independently of your source application.

The logic goes further and can support multiple fields, and search operators in the value like CUSTNR = "000115 or 0006*". Which would give you all documents of 000115 and every customer number that starts with 0006.