Durchsuchbare Dokumentation aufrufen | Zurück zur Dokumentationsübersicht
Navigation: Dokumentationen agorum core > Konfigurationen zum Import und Export
Anstelle des Metadaten-Designers bietet sich die metadata.yml-Datei an. Hier deklarierte Metadaten werden einfacher und schneller migriert. Des Weiteren ist ein Export von etwa einem Testsystem in ein Entwicklungs- oder Produktivsystem schnell und problemlos möglich.
Hinweis: Ändern Sie nachträglich keine Metadaten, da diese bereits in Verwendung sein könnten und damit im Index registriert sind. Nur der Parameter displayName darf nachträglich geändert werden. Soll jedoch etwa eine Typänderung durchgeführt werden, muss stattdessen ein neues Metadatum (mit einem neuen Namen) registriert werden.
Legen Sie Metadaten an, findet dies immer im Kontext eines Projekts statt. Hierbei definieren Sie ein Projekt als eine Konfigurationsaufgabe.
Etwa soll ein agorum core-System komplett neu für einen Interessenten angepasst werden, oder es kommt zur Konfiguration eines neuen Moduls oder Anforderungen einer Abteilung werden umgesetzt, die abteilungsspezifisch sind.
Egal, wie Sie für sich selbst ein Projekt definieren, Sie erstellen es in einem Konfigurationsordner. Dieser Ordner besitzt einen Unterordner, der sich yml nennt. Darunter befindet sich die Datei metadata.yml.
Beispiel
Eigene Dateien/Administration/customers/TestMetadata/yml
In der Datei metadata.yml werden anhand von Keywords und einem speziellen Aufbau Metadaten angelegt.
Zu Beginn einer Zeile steht entweder ein globales Keyword oder ein zu definierendes Metadatum.
Beispiel globales Keyword
_group: Demo
Ein solches Keyword beginnt mit einem Unterstrich und endet mit einem Doppelpunkt.
# Dies ist ein Kommentar
Beispiel 1
lieferantenBereich: displayName: Lieferantenbereich data: - Mails - Notizen - Dokumente - Korrespondenz
Beispiel 2
lieferantenBereich: displayName: Lieferantenbereich data: [ Mails, Notizen, Dokumente, Korrespondenz ]
Über Keywords definieren Sie Metadaten oder setzen Informationen global. Diese gelten dann für alle Metadaten.
Definiert, zu welcher Benutzergruppe die definierten Metadaten im Metadaten-Designer zugeordnet werden.
Beispiel
_group: demo
Definiert, welches Präfix vor die Namen der Metadaten geschrieben wird. Dadurch wird die yml-Datei besser lesbar.
Beispiel
_prefix: dem_
Soll ein Metadatum kein Präfix erhalten, wird ein - vor den Namen des Metadatums geschrieben:
-<metadaten-name>
Definiert, wo die Information für das Keyword data in der MetaDB abgelegt werden.
Beispiel
_dataPrefix: MAIN_MODULE_MANAGEMENT/customers/demo/Data/
Definiert, wo die CSV-Datei für das Metadatum abgelegt wird.
Beispiel
_csvPrefix: /agorum/roi/customers/demo/csv/
Definiert, welches Encoding die CSV-Datei hat.
Verwenden Sie UTF-8.
Beispiel
_encoding: UTF-8
Definiert Standard-Keywords, die zutreffen, wenn ein Metadatum keines beschrieben hat. Darunter fallen type, kind und restricted, die die folgenden Werte haben können:
type
Definiert den Datentyp des Metadatums.
Möglich sind:
kind
Definiert, um was für ein Metadatum es sich handelt.
Möglich sind:
restricted
Definiert, ob ein Wert exakt mit der Datenquelle übereinstimmen muss, oder ob auch ein eigener Wert eingegeben werden kann.
Möglich sind:
Beispiel für _default:
_default: type: string kind: inherited restricted: true
Hat ein Metadatum keine Beschreibung für diese Keywords, werden ihm automatisch die Werte string, inherited und true zugewiesen.
# _.... damit fangen Globale Einstellungen an, die hinterlegt werden können # -- global # Hier wird eingestellt, welcher Gruppe die Daten im Metadaten-Designer zugeordnet werden _group: demo # Hier wird eingestellt, welches Präfix den Metadaten vorangestellt wird # möchte man kein Präfix vor das Metadatum haben, muss dieses mit - beginnen # Beispiel: -name: Das Metadatum heißt intern "name" # Beispiel: kontrolle: Das Metadatum heißt intern dann "dem_kontrolle" _prefix: dem_ # Damit wird eingestellt, wo die Information für "data" des Metadatums in der MetaDB abgelegt werden _dataPrefix: MAIN_MODULE_MANAGEMENT/customers/demo/Data/ # Damit wird eingestellt, wo die csv-Datei für das Metadatum abgelegt wird _csvPrefix: /agorum/roi/customers/demo/csv/ # Damit wird eingestellt, welches Encoding die csv-Datei hat. _encoding: UTF-8 # Hiermit können Defaultwerte vorbelegt werden. Wenn diese dann bei der Definition eines Metadatums nicht definiert werden, werden diese auf den hier eingestellten Defaultwert gesetzt _default: # string, int, long, double, float, date, boolean type: string # inherited, notInherited, builtIn kind: inherited restricted: true
Alle Worte, die keine Keywords sind, definieren ein Metadatum. Der eingegebene Name ist der interne Name, der in der Datenbank abgelegt wird.
Beispiel
kundenName: displayName: Kunde
kundenName (ggf. + _prefix) ist der interne Name, d. h. die Bezeichnung des Metadatums in der Datenbank. Der definierte angezeigte Name für Benutzer (displayName) ist Kunde.
Im Folgenden werden die Parameter für Metadaten beschrieben.
Definiert, wie das Metadatum angezeigt wird.
Beispiel
createDate: displayName: Anlegedatum format: "dd.MM.yyyy"
In älteren Versionen von agorum core konnten auch andere Formatierungsstrings verwendet werden. Diese älteren Formatierungsstrings werden von agorum.explorer wie folgt dem aktuell gültigen Format zugewiesen:
Zweck | Alter Formatierungsstring | Aktueller Formatierungsstring |
---|---|---|
Anzeige des Datums | 'd.m.Y' |
'dd.MM.yyyy' |
Anzeige der Uhrzeit | 'H:i:s' |
'HH:mm:ss' |
Anzeige von Datum und Uhrzeit | 'd.m.Y H:i:s' |
'dd.MM.yyyy HH:mm:ss' |
Hinweis: Sie sollten in neuen Umgebungen und Konfigurationen ausschließlich die aktuell unterstützten Formatierungsstrings verwenden. Die Zuweisung von alten auf aktuell unterstützte Formatierungsstrings dient nur der Herstellung einer eingeschränkten Rückwärtskompatibilität für bestehende Installationen.
Beispiel 1
geld: displayname: Umsatz format: "0.00"
Beispiel 2
geld: displayname: Umsatz format: "#,###,##0.00 €/Monat"
Hinweis: Geben Sie das Format bei Zahlen als String an. Anstatt 0.00 tragen Sie "0.00" ein.
Definiert, mit welchem Namen das Metadatum angezeigt wird:
createDate: displayName: Anlegedatum
Soll der Name übersetzbar sein, kann stattdessen ein Übersetzungsschlüssel angegeben werden, der mit Übersetzungsdateien aufgelöst wird:
createDate: displayName: metadatum.demo.createDate
Definiert, dass der Inhalt des Metadatums aus einer externen Datenquelle kommt.
Diese Datenquellen können sein:
Bei allen Handlern können optional folgende Parameter deklariert werden.
Beschränkt die Anzahl der zurückgegebenen Elemente, die gleichzeitig angezeigt werden.
Bei der Benutzung der Datenquelle in einer Combobox können Sie definieren, wie viele Zeichen mindestens eingegeben werden müssen, bis mit einer Suche begonnen wird.
Der Standard-Wert ist 2.
Beispiel
projektMitarbeiter: displayName: Mitarbeiter data: user minChars: 1 limit: 50
Hinweis: Nachträgliche Änderungen müssen direkt in der CSV-Datei vorgenommen werden. Ein erneuter Export der yml-Datei ändert keine bereits vorhandene CSV-Datei.
Wenn nach dem Keyword data: eine Definition in [...] angegeben wird, beschreibt diese einen Eintrag aus einer CSV-Datei.
Das csv-Keyword benötigt die folgenden Standard-Keywords, damit klar ist, wohin die Einstellungsdaten geschrieben werden müssen:
Eine Definition, die zwischen [...] steht, bedeutet, dass Text und Wert der CSV-Datei gleich ist.
Beispiel data = csv (value = text)
monat: displayName: Monat data: [ "01 - Januar", "02 - Februar", "03 - März", "04 - April", "05 - Mai", "06 - Juni", "07 - Juli", "08 - August", "09 - September", "10 - Oktober", "11 - November", "12 - Dezember" ]
value;text 01 - Januar;01 - Januar 02 - Februar;02 - Februar ...
Werden die einzelnen Wertepaare angeben, können value und text verschiedene Werte annehmen:
vertragKuendigung: displayName: Kündigung data: # [ value, text ... - [ 1WocheVe, 1 Woche zum Vertragsende ] - [ 2WochenVe, 2 Wochen zum Vertragsende ] - [ 1MonatVe, 1 Monat zum Vertragsende ] - [ 3MonateVe, 3 Monate zum Vertragsende ]
Die Texte können übergesetzt werden:
Beispiel
vertragKuendigung: displayName: Kündigung # Achtung erst ab Version 1.2 von metadata-builder.js translate: text data: # [ value, text ... - [ 1WocheVe, agorum.modul.vertragsende.EineWoche ] - [ 2WochenVe, agorum.modul.vertragsende.ZweiWochen ] - [ 1MonatVe, agorum.modul.vertragsende.EinMonat ] - [ 3MonateVe, agorum.modul.vertragsende.DreiMonate ]
Möchten Sie keine data-Einträge in der Datei metadata.yml anlegen, übergeben Sie eine leere eckige Klammer data.
Beispiel
csv-nachträglich-ausfüllen-Beispiel: type: string displayName: test kind: inherited data: [ ]
Egal für welche Schreibweise Sie sich entscheiden, sobald Sie die Datei metadata.yml speichern und ausführen, wird eine CSV-Datei in dem dazugehörigen Konfigurationsordner angelegt:
/agorum/roi/customers/<Konfigurationsordner>/csv/<metadatum>.csv
Änderungen der data-Einträge müssen nun in der CSV-Datei stattfinden und nicht in der Datei metadata.yml, denn das System verwendet ausschließlich die <metadatum>.csv.
Achtung: Datenverlust durch Update (Importieren einer ZIP-Datei) möglich. Wenn Sie eine ZIP-Datei importieren, werden ggf. die CSV-Dateien im Konfigurationsordner überschrieben. Vermeiden Sie dies, indem Sie die <metadatum>.csv-Datei in den Workspace verschieben:
/agorum/roi/workspace/<Konfigurationsordner>/csv/
Passen Sie hierzu das_csvPrefix-Keyword an und verweisen Sie auf den neuen Pfad.
Sprechen Sie das Vorgehen zuvor unbedingt mit Ihrem Konfigurationspartner ab!
Wählt Benutzer und / oder Benutzergruppen.
Folgende Parameter existieren unter data:
Parameter | Beschreibung |
---|---|
data: user | Nur Benutzer wählen. |
data: user-group | Benutzer und Benutzergruppen wählen. |
data: group | Nur Benutzergruppen wählen. |
data: group-users | alle Benutzer und Benutzergruppen einer Benutzergruppe Benutzergruppe wird mit dem Keyword group: definiert. |
Beispiel
### Benutzer einer bestimmten Benutzergruppe wählen ### userFromGroupSelection: displayName: "Benutzer auswählen" data: group-users type: string kind: notInherited # Hier die Gruppe, aus der die Benutzer und Benutzergruppen gewählt werden können. Es werden auch die Benutzer und Benutzergruppen aus Untergruppen angezeigt group: GRP_agorum core Basic Archive_Read restricted: true minChars: 0 limit: 50
Sie können einen detaillierteren Einfluss auf die Benutzer-/Gruppen-Auswahl vornehmen. Dazu verwenden Sie indirekt den DataHandler user-group.
Beispiel
zur_kenntnisnahme:
data: custom
#dataSource: "MAIN_MODULE_MANAGEMENT/customers/<konfigurationsprojekt>/Data/<Name des Metadatums>"
dataSource: "MAIN_MODULE_MANAGEMENT/customers/musterfirma/Data/musterfirma_zur_kenntnisnahme"
dataSourceConfig:
# required
Class: "agorum.api.object.data.JsDataHandler"
MinChars: 0
Script: "/agorum/roi/customers/Standard/js/data/user-group.js"
# optional
ExcludeWorld: true
SearchUsers: true
Obligatorische Parameter
Parameter | Wert |
---|---|
data | custom #unverändert übernehmen |
dataSource | "MAIN_MODULE_MANAGEMENT/customers/<konfigurationsprojekt>/Data/<Name des Metadatums>" dataSource wird automatisiert angelegt, Sie tragen hier nur den Standardpfad Ihrer Metadaten ein. |
dataSourceConfig: Class |
"agorum.api.object.data.JsDataHandler" #unverändert übernehmen |
dataSourceConfig: MinChars |
0 |
dataSourceConfig: Script |
"/agorum/roi/customers/Standard/js/data/user-group.js" #unverändert übernehmen |
Optionale Parameter
Parameter | Beschreibung | Standard-Wert |
---|---|---|
AdditionalQuery | Erweitert die baseQuery um weitere Sucheigenschaften (Suche wird mit und ausgeführt). | " |
ExcludeWorld | Entfernt (false) oder fügt (true) die World-Gruppe aus/zu den Ergebnissen. | false |
GroupId | Schränkt die Suche auf die angegebene Benutzergruppe ein. Der Parameter muss eine agorum-ID des gesuchten Objekts enthalten, etwa 'group:GRP_Demo'. |
'' |
GroupTextFormat | Definiert das Format, mit dem die text-Eigenschaft von Benutzergruppen formatiert wird. | "${typeDisplayName}: ${name}" |
GroupValueFormat | Definiert das Format, mit dem die value-Eigenschaft von Benutzergruppen formatiert wird. | "${uuid}" |
Limit | Steuert, wie viele Ergebnisse zurückgegeben werden. | 100 |
MatchEnd | Erweitert die Suche, sodass die Ergebnisse mit den Wörtern der <query> enden müssen (Fuzzy Matching). | false |
MatchStart | Erweitert die Suche, sodass die Ergebnisse mit den Wörtern der <query> beginnen müssen (Fuzzy Matching). | true |
SearchGroups | Aktiviert die Suche nach Benutzergruppen. | false |
SearchUsers | Aktiviert die Suche nach Benutzern. | false |
UserTextFormat | Definiert das Format, mit dem die text-Eigenschaft von Benutzern formatiert wird. | '${typeDisplayName}: ${fullName} (${name})' |
UserValueFormat | Definiert das Format, mit dem die value-Eigenschaft von Benutzern formatiert wird. | '${uuid}' |
Hinterlegt eine Definition eines JavaScript-DataHandlers (siehe Beispiel Metadatum mit einem JS-Handler).
Beispiel
testJS: displayName: Test JavaScript data: js script: "/agorum/roi/customers/test/js/JSDataHandler.js"
Erstellt einen Suchhandler, der im vom Metadatum angelegten Feld (wird bei Setzen des Metadatums erzeugt) eine Suche durchführt.
Der Rückgabewert ist im Standard, wenn nichts angegeben wird, der name des Objekts. Dieser kann mit den beiden Keywords value und text gesetzt werden.
aktenName: data: search query: ... text: name # Hier wird die ID des Objektes zurückgegeben value: id
Wenn es sich bei text oder value um ein nicht vererbtes Metadatum handelt, muss ~ vorangestellt werden.
Beispiel
rechnungsNummer: data: search query: ... # prefix des Projektes muss hier mit angegeben werden text: ~prefix_rechnungsNummer # Hier wird die ID des Objektes zurückgegeben value: id
Wenn es sich bei text oder value um ein vererbtes Metadatum handelt, muss ~~ vorangestellt werden. Da ein Array zurückgegeben wird, muss das erste Element mit [0] ausgelesen werden.
Beispiel
kundenName: data: search query: ... # prefix des Projektes muss hier mit angegeben werden text: ~~prefix_kundenName[0] # Hier wird die ID des Objektes zurückgegeben value: id
Hinweis: Wird data: search gesetzt, muss zwingend dazu das Keyword query angegeben werden, das die Suche beschreibt.
Hinweis: Die Nutzung von Abhängigkeiten durch die Query müssen in agorum core aguila-Konfigurationen noch mal gesondert abgefangen werden.
Wenn ein Metadatum gesetzt wird, können Sie als Entwickler nicht nur einen Einfluss darauf nehmen, welchen Datentyp das Metadatum hat, sondern auch, ob der Benutzer Vorschläge bei seiner Eingabe angezeigt bekommt. Diese Vorschläge können Sie anhand einer Query definieren und von anderen Metadaten abhängig machen.
Dabei gelten folgende Regeln:
?<Feld>
Feld des Objektes/ Metadatums, in dem der vom Benutzer eingegebene Text gesucht wird, etwa:
query: [ ?name ]
+<Wert>
Möchten Sie eine Abhängigkeit zu einem bestimmten Identifier setzen, verwenden Sie entweder das Metadatum identifer oder ein Plus-Zeichen vor dem zu suchenden Wert.
Dieses Beispiel kann auch so geschrieben werden:
query: [ identifier:Bestellakte ] //zu bevorzugen, da diese Schreibart leserlicher ist // oder query: [ +Bestellakte ]
<Wert>
Verwenden Sie etwa eine Eingabeoberfläche des agorum core explorers, um verschiedene Metadaten abzufragen, können Sie die Eingaben aufbauend voneinander in Abhängigkeit setzen.
Beispiel
Die Auswahl an Werten des Lieferantenstatus soll abhängig vom gewählten Lieferant sein. Hierzu sollte das Metadatum des Lieferantenstatus eine Query enthalten, die als Wert den Lieferanten enthält (Parameters).
Der Wert ist der Name eines Metadatums, nach dem gesucht wird und dessen Inhalt in der Eingabeoberfläche definiert wurde.
In der Datei metadata-yml passen Sie die Query wie folgt an:
query: [ aktesection ]
Gesucht wird jetzt nach einem Wert, der das Metadatum acbasicarchive_aktesection in den Parameters enthält.
Die folgende Query führt zu demselben Ergebnis, wird nur länger ausgeschrieben:
query: [ "acbasicarchive_aktesection:'${acbasicarchive_aktesection}'" ] // Das System sucht somit innerhalb des Metadatums acbasicarchive_aktesection nach dem übergebenen Wert aus der Eingabeoberfläche ${acbasicarchive_aktesection}. // Verwenden Sie diese Schreibweise, müssen Sie den Präfix mit angeben.
Das Präfix wird automatisch gesetzt und bezieht sich somit automatisch auf Metadaten, die in derselben metadata.yml definiert wurden.
Möchten Sie auf ein Metadatum verweisen, das ein anderes Präfix besitzt, setzen Sie ein führendes Minuszeichen (-) vor das Metadatum.
query: [ -sample_aktesection ] // Sie verweisen durch das Minus somit auf das Metadatum "sample_aktesection" eines anderen Projektes
Die gesetzten Abhängigkeiten müssen sich nicht auf die Eingabewerte einer Eingabeoberfläche beziehen. Genauso gut können Sie feste und immer gültige Werte eintragen. Hier ein Beispiel, in dem festgelegt wird, dass das Metadatum area den Wert mandanten haben muss:
query: [ (area:mandanten) ]
Sie können auch mehr als eine Abhängigkeit:
query: [ "acbasicarchive_aktesection_cs:${acbasicarchive_aktesection}", "acbasicarchive_aktearea_cs:${acbasicarchive_aktearea}" ]
Jeder Wert ergänzt die auszuführende Query nur, wenn die Ersetzung geklappt, d. h. wenn das zu ersetzende Metadatum auch vorhanden ist.
Alle Abhängigkeiten sind mit einem UND zueinander verknüpft, und alles muss für die anzuzeigenden Werte zutreffen.
Beispiel
aktenName: data: search query: [ ?name, +Bestellakte, lieferantenakte, lieferantBereich, rahmenabschlussakte, einzelabschlussakte, bestellungJahr, area:mandanten, dem_aktenzeichen:abc* ]
Sind keine der oben angegebenen Metadaten belegt worden, wird nach name:([Eingabe]) identifier:Bestellakte area:mandanten dem_aktenzeichen:abc* gesucht.
Wäre das Metadatum lieferantenakte mit abc belegt, sieht die Suche so aus:
name:([Eingabe]) identifier:Bestellakte dem_lieferantenakte:abc area:mandanten dem_aktenzeichen:abc*
Verweist auf einen vorhandenen MetaDB-data-Eintrag:
Beispiel
aktenName: data: custom dataSource: "MAIN_MODULE_MANAGEMENT/customers/Standard/aktenName"
Ermöglicht es, einem Metadatum mehrere Werte zuzuweisen. Sie erhalten damit bei der Abfrage ein Array zurück.
Beispiel
jahr: displayName: jahr data: [ 2015, 2016, 2017, 2018, 2019, 2020 ] multi: true
Hier ist es möglich, dem Metadatum dem_jahr mehrere Werte zuzuordnen.
Definiert, ob das Metadatum geändert werden kann.
Wert | Beschreibung |
---|---|
true | Metadatum kann nicht geändert werden. |
false (Standard) | Metadatum kann geändert werden. |
Beispiel
bezeichnungTask: displayName: Task readOnly: true
Definiert, ob es sich um ein optionales Feld oder ein Pflichtfeld handelt.
Wert | Beschreibung |
---|---|
true | Feld ist optional. |
false (Standard) | Feld ist Pflicht. |
Beispiel
bezeichnungTask: displayName: Task optional: true
Schlägt automatisch alle für dieses Metadatum schon einmal eingegebenen Daten vor, sodass Sie aus diesen wählen können.
Beispiel 1 für facet
holdingBereich: displayName: Bereich data: search facet: -name query: [ +Holding GmbH ]
Hier wird innerhalb vom holdingBereich im facet Name (ohne Präfix) nach allem, was den Identifier Holding GmbH besitzt, gesucht.
Beispiel 2 für facet der vereinfachten, inzwischen bevorzugten Schreibweise:
holdingBereich: displayName: Bereich type: string kind: notInherited data: search facet: query: []
Hierdurch werden automatisch alle Werte angeboten, die das Metadatum holdingBereich im System bereits hat.
regex stellt per RegExp ein Muster ein, dem die Eingabe entsprechen muss.
regexText stellt dagegen den Text ein, der ausgegeben wird, wenn das Muster der Eingabe nicht stimmt.
Damit es bei der Eingabe korrekt validiert und eine Falscheingabe signalisiert wird, halten Sie die folgende Schreibweise ein:
"^<regex Ausdruck>$" //^: Anfang des Ausdrucks //$: Ende des Ausdrucks
Beispiel
MandantenNr: displayName: Mandanten-Nr # validation regex: "^ma[345][0-9]{2,2}$" regexText: "Folgendes Format eintragen: maXYY (wobei X: 3-5 und Y: 0-9 ist)"
Hinweis: Soll das regex-Feld auch optional sein (typischerweise auch bei Verwendung in einer Suchmaske der Fall), muss ein leerer Ausdruck angefügt werden:
"(^ma[345][0-9]{2,2}$)|^$").
Testen
Um Ihre regex-Ausdrücke zu testen, erstellen Sie ein JavaScript in agorum core und fügen Sie folgenden Code ein:
'<String>'.match(/^<regex-Ausdruck>$/);
Beispiel
Definiert die Darstellung eines Metadatums in Formularen.
Das Metadatum wird für Drop-down-Felder (bei gesetztem data-Keyword) automatisch belegt.
Wert | Beschreibung |
---|---|
default | Standard-Darstellung, sollte nicht explizit angegeben werden. |
dataSource | Drop-down-Darstellung, sollte nicht explizit angegeben werden. |
textArea | mehrzeiliges Textfeld |
password | Stellt ein Textfeld als Passwort dar (nur in Kombination mit form). |
Definiert, welche Spalten (value oder text) der Datenquelle für die Anzeige übersetzt werden müssen.
Beispiel
fileType: displayName: _agorum.sample.fileType.displayName translate: text data: - [ customer, agorum.sample.fileType.customer ] - [ supplier, agorum.sample.fileType.supplier ]
Definiert das Metadatum als Liste (etwa Rechnungsposition) und ermöglicht gleichzeitig die Definition von Elementen innerhalb dieser Liste (etwa Nummer der Rechnungsposition).
Diese Elemente sind analog zur Definition von Positionen innerhalb von docform-Typen (ein docform-Typ hat mehrere Positionen).
Beispiel
invoice_items: displayName: Rechnungspositionen list: number: displayName: Nummer type: string description: displayName: Bezeichnung type: string net: displayName: Nettobetrag type: double
Für das Suchen nach einem list-Metadatum siehe Suchsyntax in Solr verwenden.
Achtung: Beeinträchtigung der Systemleistung durch Verwendung zu vieler Metadaten in einer Liste. Wenn Sie zu viele Metadaten in einer Liste verwenden, lädt das System die Liste extrem langsam. Verwenden Sie daher nur ein einzelnes Metadatum in einer Eingabeoberfläche und niemals in einer Liste.
Übersetzt vor der Anzeige der Wert des Metadatums durch translate und kommt dann erst zur Anzeige.
-_([~ oder ~~ oder nichts]<Name des Metadatums):
Wert | Beschreibung |
---|---|
- | Bei einem - wird kein Präfix vor das Metadatum geschrieben. Wenn dieses trotzdem eines benötigt, muss das Präfix mit zum Name des Metadatums geschrieben werden. |
_ | Definiert, dass der Inhalt übersetzt wird. |
( | Nach ( beginnt der Name des Metadatums in derselben Syntax wie bei der JavaScript-Bibliothek common-beans. kind hat folgende Bedeutung:
|
Internes Metadatum
-_(workflowDefinition.description): displayName: Workflow-Art kind: builtIn type: string readOnly: true
Nicht vererbtes Metadatum
-_(~acmf_beispielNichtVererbt): displayName: Workflow-Art kind: notInherited type: string readOnly: true
Vererbtes Metadatum
-_(~~acmf_beispielVererbt): displayName: Workflow-Art kind: inherited type: string readOnly: true
Tipp: Durch Auskommentieren können Sie Ihre metadata.yml reversibel verändern, im folgenden Beispiel an # readOnly dargestellt.
# -- global _group: demo _prefix: dem_ _dataPrefix: MAIN_MODULE_MANAGEMENT/customers/demo/Data/ _csvPrefix: /agorum/roi/customers/demo/csv/ _encoding: UTF-8 _default: # string, int, long, double, float, date, boolean type: string # inherited, notInherited, builtIn kind: inherited restricted: true MandantenNr: displayName: Mandanten-Nr data: search # readOnly: true facet: query: [ ] restricted: false regex: "^ma[345][0-9]{2,2}" regexText: "maXYY (X: 3-5, Y: 0-9)"
Eigene Dateien/Administration/customers/<Name der Konfiguration>/yml/export.yml
Hinweis: Diese Aktion erscheint nur, wenn der Dateiname mit export beginnt und mit .yml endet.
Die metadata.yml-Datei wird im Zuge eines Konfigurationsprojektes erstellt und liegt in einer speziellen Ordnerstruktur vor (siehe ZIP-Dateien und Konfigurationsprojekte installieren). In dem yml-Ordner muss für einen Export eine export.yml-Datei (siehe Beschreibung der Datei "export.yml") definiert sein. Diese Datei erstellt ein ZIP-Package des kompletten Konfigurationsordners und schließt somit auch die metadata.yml mit ein.
Für einen direkten Import während der Installation des ZIP-Packages muss ein JavaScript vorliegen, dass die yml-Datei gleich installiert und ausführt.
Um die Metadaten aus einer metadata.yml beim Import wieder auszulesen, kann diese in einem Package mit JavaScript eingebunden werden. Dieses wird dann im Ordner deploy abgelegt.
Beispiel
/agorum/roi/customer/<NamederKonfiguration>/deploy/pre/js/02-metadata.js
/* global sc */ let mb = require('/agorum/roi/customers/Standard/js/metadata-builder'); let yaml = require('common/objects').find('/agorum/roi/customers/<NamederKonfiguration>/yml/metadata.yml').contentString; mb(yaml).install(sc);