...
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):
| Code Block |
|---|
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:
| Code Block |
|---|
global-properties:
customFields:
CUSTNR: YourDefaultValue |
...
Restart the backend, go to the user administration and open the user of your customer “000115““000115”.
Set the field CUSTNR to "000115"“000115”:
...
After you saved the settings, the next time the user opens the section the view is already filtered:
...
And you’re done. ✌️ You just solved an issue nobody else could wrap their head around for years.
Synopsis
The Custom Fields are an extremely 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 chained values 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.
...