pyrusd  1.2.0
About: Main//Pyrus is an enterprise scale Open-Source Document Management System (DMS) - Daemon.
  Fossies Dox: pyrusd-1.2.0.tar.gz  ("inofficial" and yet experimental doxygen-generated source code documentation)  

pyrusd Documentation

Einführung

Dies ist Dokumentation des Main//Pyrus Dokumenten Archivierungs Dämon. Für das Main//Pyrus Webinterfaces existiert eine eigene Dokumentation.

Der Main//Pyrus Archivierungsdaemon teilt sich in zwei Teile:

  • pyrusd Der Dämon Prozess
  • pyrus Ein Client Programm

pyrusd

Der Dämon Prozess ist so konzipiert, das er bei Systemstart gestartet werden kann. Er muss mit root Rechten laufen. Er stellt die komplette Schnittstelle zum pyrus Verzeichnisbaum bereit. Alle andersartigen Zugriffe sollten verhindert werden.

Der Dämon Prozess, im folgenden Server, ist ein multithreadingfähiger SSL Server. Er wartet auf standardmäßig auf Port 7707 auf ein kommende Verbindungen. Er archiviert eingehende Dokumente und gibt archivierte Dokumente aus. Dafür benötigt er einen MySQL Server der Version >= 4.1.2.

Der Server nimmt nur SSL Verbindungen an. Der Client wird über sein X509-Zertifikat verifiziert. Das Zertifikat des Clients muss vom Server zertifiziert sein. Sonst wird die Verbindung abgelehnt. Durch diese Vorgehensweise kann ein Client automatisch sich verifiziert werden, ohne das ein Passwort notwendig ist.

Für die Syntax des Client-Server Protokolls siehe do_server_loop().

pyrus

Der pyrus Client, im folgenden Client, baut eine Verbindung zum Server auf und übermittelt Dokumente für die Archivierung. Alternativ kann er archivierte Dokumente vom Server holen, bearbeiten oder löschen.

Der Client sollte nicht mit root Rechten laufen. Er verifiziert sich gegenüber dem Server mittels seines X509-Zertifikates.

Installation

Zum compilieren des Main//Pyrus Archivierungsdaemons werden, zusätzlich zu den Standardbibliotheken, folgende Bibliotheken benötigt:

  • OpenSSL 0.9.7
  • MySQL >= 4.1.2 (Thread-safe)

Zur Laufzeit werden folgende Programme benötigt:

  • sendmail
  • gs
  • psselect

Wenn die angegebenen Bibliotheken installiert sind, kann pyrus mit make erstellt und mit make install installiert werden.

Verzeichnisse

Das einzige fest definierte Verzeichnis ist das der Config Dateien. Sie müssen im Verzeichnis /etc/pyrus/ liegen. Die Config Datei des Servers heißt pyrusd und die des Client heißt pyrus. Das Config Verzeichnis lässt sich durch eine Compileroption ändern.

In der Config Datei des Servers werden die restlichen Verzeichnisse definiert. Standardmäßig sind das

  • /etc/pyrus/ssl Für die SSL Schlüssel und Zertifikate
  • /var/pyrus Zum zwischenspeichern eingehender Dokumente
  • /var/log/pyrus Für die Logdatei
  • /var/log/pyrus Für die PID Datei
  • /opt/pyrus Für den Verzeichnisbaum

SSL

Da die Client-Server Verbindung via SSL X509-Zertifikate verifiziert wird, ist es für eine erfolgreiche Verbindung zum Server Voraussetzung das die Zertifikate richtig erstellt wurden. Für eine maximale Sicherheit werden vom Server nur Zertifikate akzeptiert, welche bis maximal zur Tiefe 2, von der CA zertifiziert wurden. Das openssl Kommandozeilentool stellt hierfür alle benötigten Befehle zur Verfügung.

Folgende Schritte sind dabei durchzuführen:

  1. Erstellen einer root Autorität
    • Erstellen des root Schlüssels
      openssl req -newkey rsa:1024 -sha1 -keyout rootkey.pem -out rootreq.pem
    • Erstellen des root Zertifikates
      openssl x509 -req -in rootreq.pem -sha1 -signkey rootkey.pem -out rootcert.pem
      cat rootcert.pem rootkey.pem > root.pem
  2. Erstellen der CA (Certificate Authority)
    • Erstellen des CA Schlüssels
      openssl req -newkey rsa:1024 -sha1 -keyout serverCAkey.pem -out serverCAreq.pem
    • Erstellen des CA Zertifikates und signieren mit dem root Schlüssel
      openssl x509 -req -in serverCAreq.pem -sha1 -CA root.pem -CAkey root.pem \\
      -CAcreateserial -out serverCAcert.pem
      cat serverCAcert.pem serverCAkey.pem rootcert.pem > serverCA.pem
  3. Erstellen des Server Schlüssels und Zertifikates
    • Erstellen des Server Schlüssels
      openssl req -newkey rsa:1024 -sha1 -keyout serverkey.pem -out serverreq.pem
    • Erstellen des Server Zertifikates und signieren mit dem CA Schlüssel
      openssl x509 -req -in serverreq.pem -sha1 -CA serverCA.pem -CAkey serverCA.pem \\
      -CAcreateserial -out servercert.pem
      cat servercert.pem serverkey.pem serverCAcert.pem rootcert.pem > server.pem
  4. Erstellen des Client Schlüssel und Zertifikates
    • Erstellen des Client Schlüssels
      openssl req -newkey rsa:1024 -sha1 -keyout clientkey.pem -out clientreq.pem
    • Erstellen des Client Zertifikates
      openssl x509 -req -in clientreq.pem -sha1 -CA root.pem -CAkey root.pem \\
      -CAcreateserial -out clientcert.pem
      cat clientcert.pem clientkey.pem rootcert.pem > client.pem

Die Angegebenen Dateinamen sind natürlich beliebig. Sie sind die Standardwerte können aber beliebig in der pyrusd Config Datei geändert werden.

Die angegebenen Kommandos beziehen sich auf das openssl Kommandozeilentool unter Linux. Die Kommandos sind die minimal notwendigen für einen funktionierenden Verbindungsaufbau. Selbstverständlich können die Kommandos noch weiter verfeinert werden. Für sehr sensitive Server ist dies sogar zu empfehlen. Für eine ausführliche Dokumentation der openssl Befehle beachte Sie bitte die zu openssl gehörige Dokumentation.

Es wird empfohlen den Schlüsseln Passwörter zu geben. Diese Passwörter müssen dann in der entsprechenden Config Datei liegen.

XML-Config Datei

Eine zentrale Aufgabe des Servers besteht in der Analyse einer xml Datei, welche die Struktur des abzulegenden Dokumentes beschreibt.

Hier folgt eine kurze Beschreibung der Syntax dieser xml Datei. Es ist zu beachten das die Struktur der xml Datei syntaktisch korrekt sein kann, aber trotzdem Fehler verursachen kann. Dies tritt auf wenn:

  • Nicht vorhandene logische Strukturen (Klassen, Columns, etc. ) angesprochen werden.
  • Nicht vorhandene Benutzer/Gruppen referenziert werden.
  • Attribute von Strukturen verletzt werden (unique, etc.).

Wenn Fehler in dieser Datei auftreten, wird versucht diese zu ignorieren und das Dokument ohne die falsche Information abzuspeichern. Fehler, bei denen das Dokument immer abgelehnt werden muss, sind:

  • nicht genau EINE config Datei mitgeliefert. Werden mehrere config Dateien mitgeliefert kann dem Client gesagt werden das eine Datei die config Datei ist. Dadurch kann dieses Problem aufgelöst werden. Sonst hat der Server keine Möglichkeit zu wissen wie das Dokument abgelegt werden soll.
  • Keine wohlgeformte xml Syntax.
  • unbekannter login.

Ein Datum muss in der der Datei immer in folgender Notation stehen: JJJJ-MM-TT. Bei einem Datums Zeit Feld kann optional die Zeit mit angegeben werden. Die Notation ist dann wie folgt: JJJJ-MM-TT HH:MM:SS.

Die Reihenfolge untenstehender Abschnitte ist egal.

Anfang

Gemäß der XML Spezifikation muss die Datei mit der Zeile

<?xml version="1.0" encoding="ISO-8859-1"?>

anfangen. Als pyrus Struktur Datei wird sie durch den darauffolgenden Tag erkannt:

<!DOCTYPE pyrus>

Gemäß xml Syntax muss der nächste Tag, der durch DOCTYPE spezifizierte sein.

<pyrus version="0.2">

Die Versionsnummer wird momentan nicht überprüft.

Gemäß xml Syntax muss die config Datei mit

aufhören. Dahinter darf keine weitere Information stehen.

<auth>

Dieser Abschnitt wird durch

<auth>

eingeleitet. Wenn dieser Abschnitt mehr als einmal auftritt, überschreiben die Werte des letzten Abschnitts alle vorherigen Werte.

In diesem Abschnitt wird definiert für wen, bzw. wer ein Dokument hinzufügt. Der Abschnitt login ist obligatorisch. Wird keine Gruppe (s.u.) angegeben, so ist durch den Login auch der Besitzer des Dokumentes festgelegt und alle notwendigen Rechte zum Import des Dokumentes beziehen sich auf den Benutzer.

<login>mustermann</login>

Wenn obiger Benutzer das Dokument für eine Gruppe hinzufügen möchte, dann kann er optional eine Gruppe spezifizieren. Diese Gruppe ist dann die Besitzerin des Dokumentes. Es muss der Name der Gruppe, nicht ihre Id, angegeben werden.

Wird eine Gruppe angegeben, so benötigt die Gruppe die notwendigen Rechte für den Import des Dokumentes.

Wenn der Benutzer nicht zu der Gruppe gehört wird ein Fehler ausgegeben und das Dokument wird mit dem Benutzer als Besitzer abgespeichert.

<group>foo</group>

Optional kann auch eine email angegeben werden

<email>foo@bar.com</email>

Der Inhalt dieses Tags wird jedoch zur Zeit nicht ausgewertet.

Der Abschnitt endet mit:

</auth>

<document>

In diesem Abschnitt werden globale Attribute des Dokumentes spezifiziert. Er wird durch:

<document>

eingeleitet. Wenn dieser Abschnitt mehr als einmal auftritt, überschreiben die Werte des letzten Abschnitts alle vorherigen Werte.

Die Attribute Title, Autor, CreateDateTime, Content und nativeFile

<title>bar</title>
<author>Max Mustermann</author>
<createDateTime>2004-02-11</createDateTime>
<content>Beispieltext</content>
<nativeFile>fooBar</nativeFile>

Boolsche Werte können als TRUE bzw. 1 und FALSE bzw. 0 angegeben werden.

Der Abschnitt wird beendet durch:

</document>

<class>

Da ein Dokument mehreren Klassen angehören kann, kann dieser Abschnitt auch mehrfach angegeben werden. Wird jedoch dieser Abschnitt für eine Klasse wiederholt, werden die vorherigen Werte überschrieben.

Im einleitenden Tag muss die Klasse spezifiziert werden. Dies kann durch die Angabe von der Id und/oder des Namens der Klasse geschehen. Wenn Name und Id angegeben sind, müssen beide auf die selbe Klasse verweisen, sonst wird die Information dieser Klasse ignoriert.

<class id="42" name="Rechnungen">

Ein Benutzer braucht das nötige Recht um in eine Klasse zu schreiben. Wenn der Benutzer das Recht nicht hat, wird die zu dieser Klasse gehörende Information ignoriert.

Der Abschnitt der Klasse behinhaltet die Abschnitte <column> und <acl>, sowie die Felder die ein logisches Dokument besitzt. Das sind docExpireDate, docExpireMandatory und docAutoDelete. Sie werden wie folgt definiert:

<expire>2005-02-11</expire>
<expireMandatory>TRUE</expireMandatory>
<autoDelete>0</autoDelete>

Der Abschnit class wird beendet durch:

</class>

<column>

Eine Column kann, analog zu einer Klasse, durch den Namen und/oder seine Id spezifiziert werden. Wenn beides angegeben ist und nicht dieselbe Column referenziert, wird der Inhalt der Column ignoriert. Columns können Attribute haben die bei Missachtung Fehler produzieren. Das sind:

  • unique : Eine Column die unique ist, darf nur einen value aufnehmen.
  • required : Eine Column die required ist, muss angegeben sein. Wenn sie nicht angegeben ist, wird die Information der ganzen Klasse ignoriert.
  • lookupMandatory : Eine Column die lookupMandatory ist, kann nur eine fest definierte Menge an Werten annehmen. Wenn ein Wert hinzugefügt werden soll, der nicht zu dieser Menge gehört, so wird dieser ignoriert.
  • formatString : Zu einer Column kann ein FormatString definiert sein. Wenn dieser verletzt wird, so wird der Wert dieser Column abgelehnt.
  • Die Column muss zu der Klasse gehören, als deren Untergruppe sie definiert wurde. Sonst wird die Column ignoriert.

Eine Column wird wie folgt definiert:

<column id="1" name="Rechnungsnummer">

Innerhalb dessen werden values definiert. Diese müssen obige Eigenschaften der Column genügen.

<value>0815</value>
<value>0816</value>

Eine Column wird durch

</column>

beendet.

<acl>

In diesem Abschnitt können Rechte für einen Benutzer oder eine Gruppe an dem Dokument definiert werden. Die Rechte gelten nur für die Informationen die sich auf die Klasse beziehen, dessen Unterabschnitt der <acl> Abschnitt ist.

Die Gruppe oder der Benutzer können auch hier durch die Id und/oder den Namen angegeben werden. Wenn beides angegeben wurde und nicht auf den selben Benutzer/die selbe Gruppe referenziert, so wird der ACL Eintrag abgelehnt.

Wenn ein Benutzer/eine Gruppe mehrfach auftritt werden die maximal vergegbenen Rechte vergeben.

Der Abschnitt wird durch

<acl>

eingeleitet.

Folgende Rechte können vergeben werden:

  • read : Leserecht
  • write : Schreib-/Ändernrecht
  • delete : Löschrecht
  • native : Zugriffsrecht auf das Native Format. Damit dieses Recht einen Sinn macht, muss im Abschnitt <document> der Wert nativeFile gesetzt sein.
  • grant : Das Recht seine eigenen Rechte zu vererben.
  • revoke : Das Recht Rechte zurückzunehmen.
  • manager : Alle Rechte zusammen. Das Recht repräsentiert das gleiche Recht das auch der Besitzer des Dokumentes hat, mit der Ausnahme, dass nur der Besitzer den Besitzer ändern kann.

Der Besitzer des Dokumentes hat per definitionem ALLE Rechte an einem Dokument. Es ist also nicht nötig, das er sich explizit Rechte gibt.

Jedes Recht kann als Wert entweder 1, 0 oder -1 annehmen. Wenn ein Recht nicht angegeben ist, findet der Standardwert 0 Verwendung. Einzelne Einträge werden wie folgt definiert:

<user id="1" name="foo" read="1" write="0" manager="-1" />
<group id="42" name="bar" read="1" write="1" grant="-1" revoke="-1" />

Der Abschnitt wird durch

</acl>

beendet.

<project>

Dieser Abschnitt ist Unterabschnitt zu dem Abschnitt class. In ihm werden die Projekte spezifiziert, zudem das jeweilige logische Dokument hinzugefügt werden soll. Ein Projekt wird über eine Id und/oder Namen angesprochen. Wenn beides angegeben wurde dann müssen sie auf dasselbe Projekt referenzieren, ansonsten wird das Projekt abgelehnt. Soll ein logisches Dokument zu mehreren Projekten hinzugefügt werden, dann muss für jedes Projekt ein einzelner Abschnitt angegeben werden.

Projekte sind von ihrer Struktur her ähnlich aufgebaut wie Klassen/Columns. Unterscheiden tut sie, dass Projekte beim Import erstellt werden können. Dies geschieht, wenn das Projekt durch einen Namen angesprochen wird der nicht existiert. Da Projekten Projekttypen zugeordnet sind, muss, wenn das Projekt erzeugt werden soll, ein Projekttyp mit angegeben sein. Dies kann durch die die Attribute type_id und type_name geschehen. Es ist zu beachten, dass ein Benutzer das CREATE Recht auf den Projekttyp besitzen muss, damit die Aktion erfolgreich durchgeführt werden kann.

Existiert das Projekt bereits, so werden die Attribute type_id und type_name ignoriert. Mittels des Parameters update kann gesteuert werden, ob die Felder des Projektes geändert werden (update="yes") oder nicht. Wird der Parameter nicht übergeben, so werden die Felder standardmäßig nicht geändert.

Der Abschnitt wird durch

<project>

eingeleitet.

Als Parameter können

  • id: Id des Projektes.
  • name: Titel/Name des Projektes
  • type_id : Id des Projekttyps
  • type_name : Name des Projekttyps
  • update : Ob bestehendes Projekt geändert werden soll

übergeben werden.

So wie einer Klasse eine bestimmte Menge an Columns zugeordnet sind, so sind den Projekten Felder (fields) zugeordnet. Diese können über ihre Id und/oder ihren Namen angesprochen werden. Felder können required, unique, (nur) Werte aus einer Lookuptabelle übernehmen und nach einem Format String formatiert sein müssen. Wenn zwingende Attribute nicht erfüllt wurden, so führt das dazu, dass möglicherweise das gesamte Projekt abgelehnt wird, mindestens aber einige Werte nicht abgespeichert werden.

Ein Feld wird durch den Tag

<field id=12>

eingeleitet. Innerhalb dieses Tags können mehrere Werte (values) stehen

<value>Foo</value>
<value>Bar</value>

Geschlossen wird ein Feld durch den Tag

</field>

Jeder Abschnitt eines Projektes hat einen ACL Abschnitt, der analog zu dem einer Klasse aufgebaut ist. Der Abschnitt fängt mit

<prjAcl>

an.

Folgende Rechte können vergeben werden:

  • read : Leserecht
  • write : Schreib-/Ändernrecht
  • manager : Recht um die Felder der Projektes nachträglich zu ändern.

Der Besitzer des Projektes hat per definitionem ALLE Rechte an einem Projekt. Es ist also nicht nötig, das er sich explizit Rechte gibt.

Jedes Recht kann als Wert entweder 1, 0 oder -1 annehmen. Wenn ein Recht nicht angegeben ist, findet der Standardwert 0 Verwendung. Einzelne Einträge werden wie folgt definiert:

<user id="1" name="foo" read="1" write="1" manager="-1" />
<group id="42" name="bar" read="1" write="0" manager="-1" />

Der Acl-Abschnitt wird mit

</prjAcl>

und der Projekt Abschnitt durch

</project>

beendet.

Memos

In einem Klassenabschnitt kann eine beliebige Anzahl an Memos angegeben werden. Memos übernehmen als Parameter

  • date : Der Zeitstempel der als Erstellungsdatum der Memo gespeichert werden soll
  • author : Der Name des Autors der Memo

Ein Memoabschnitt hat also Beispielsweise die Form:

<memo date="2006-04-28 10:50:26" author="Foo Bar">
Dies ist eine Memo
</memo>

XML-Spezifikations Datei

Das System stellt eine Datei (spec.xml) bereit, welche über die aktuelle Konfiguration des Systems Auskunft gibt. Felder welche binäre Werte enhalten werden in folgender Form ausgegeben:

<foo>0</foo>
<bar>1</bar>

Allerdings können binäre Felder welche den Wert 0==false beinhalten auch unterdrückt werden und nicht angezeigt werden. Beim parsen der spec.xml Datei ist also für binäre Felder immer von einem Standardwert 0 auszugehen.

Die Reihenfolge in der die einzelnen Felder angegeben werden kann sich ändern. Ein Parser darf sich nicht auf Reihenfolge der angegebenen Felder verlassen.

Die Datei fängt mit der xml Deklaration an:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE pyrus>
<pyrus version="0.2" type="specification">

<server>

Im Abschnitt <server> werden allgemeine Attribute des Servers publiziert:

<server>
<name>Main//Pyrus Testserver</name>
<ip>10.1.1.10</ip>
<comment>Dies ist der Main//Pyrus-Entwicklungsserver. Die IP-Adresse ist lokal.</comment>
<date_of_report>2006-2-2</date_of_report>
</server>

<users>

In diesem Abschnitt werden alle Benutzer des Systems aufgeführt. Für jeden Benutzer existiert ein Abschnitt der Gestalt:

<user id="2">
<firstname>Benutzer</firstname>
<lastname>Admin</lastname>
<title></title>
<login>admin</login>
<sysManager>1</sysManager>
</user>

Das Feld sysManager ist binär.

<groups>

In diesem Abschnitt werden alle Gruppen des Systems aufgeführt, sowie alle Mitglieder die eine Gruppe hat werden aufgelistet.

<group id="2">
<name>Firmen Anwender</name>
<description>alle Benutzer die Zugang zu den Firmen Klassen haben</description>
<members>
<group id='1' />
<user id="3">
<manager>1</manager>
</user>
</members>
</group>

Von der oben angegeben Gruppen sind die Gruppe mit der Id=1 und der Benutzer mit der Id=3 Mitglieder. Der angegebene Benutzer ist Manager dieser Gruppe, wäre er dies nicht, so könnte das binäre Feld <manager> entfallen und das Feld <user> würde zusammengezogen werden können. Es sähe dann so aus wie das Feld group innerhalb von members.

<classes>

In diesem Abschnitt werden alle Klassen einzeln aufgeführt. Für jede Klasse existiert ein Abschnitt der Gestalt:

<class id="2">
<name>Lieferscheine</name>
<description>(Firma)</description>
<storageDuration days="" />
<storDurMandatory>0<storDurMandatory>
<storDurAutoDelete>0<storDurAutoDelete>
<autoRelease>1<autoRelease>

Dies definiert eine Klasse mit der Id 2, der Namen "Lieferscheine", der Beschreibung "(Firma)". Boolsche Felder sind:

  • storageDuration
  • storDurMandatory
  • storDurAutoDelete
  • autoRelease

als boolsche Felder müssen sie nicht aufgeführt werden. Sind sie nicht vorhanden, so ist "0" als ihr Wert anzunehmen.

Zu jeder Klasse gehört eine beliebige Anzahl an Columns. Diese werden durch einen Abschnitt der Gestalt:

<column id="6">
<name>Kunden-Nummer</name>
<datatype></datatype>
<formatString>[###]</formatString>
<lookRefId>1</lookRefId>
<tooltip></tooltip>
<globalSearch>1</globalSearch>
<lookupMandatory>0</lookupMandatory>
<required>1</required>
<unique>1</unique>
</column>

definiert. Die hier gezeigte Column hat die Id 6, den Namen "Kunden-Nummer", keinen Datentypen, den FormatString "[###]", ist mit der Lookup Tabelle 1 verknüpft und hat keinen Tooltip Boolsche Felder sind:

  • globalSearch
  • lookupMandatory
  • required
  • unique

als boolsche Felder müssen sie nicht aufgeführt werden. Sind sie nicht vorhanden, so ist "0" als ihr Wert anzunehmen.

Da nur bestimmte Benutzer Dokumente zu einer bestimmten Klasse hinzufügen dürfen, steht innerhalb jedes class Abschnittes ein Abschnitt der Gestalt:

<aclWRITE>
<group id="2" />
<user id="3" />
<user id="6" />
</aclWRITE>

Nach diesem Abschnitt, darf die Gruppe mit der Id 2, und die Benutzer mit der Id 3 und 6 Dokumente zu dieser Klasse hinzufügen. Es ist zu beachten, dass die Rechte des Benutzers entscheidend sind. Die Gruppen werden nur ausgegeben um eventuell einen Konflikt zu erkennen, wenn ein Benutzer ein Dokument für eine Gruppe hinzufügen möchte.

Der Abschnitt einer Klasse wird mit

</class>

beendet. Wurden alle Klassen ausgegeben, so wird der Abschnitt mit

</classes>

beendet.

<lookUpTables>

In diesem Abschnitt werden die Lookup Tabellen angegeben. Er hat die Form:

<lookUpTables>
<lookUp refId="1" refName="Kunden Nummern">
<value>101</value>
<description>Sanitär Müller</description>
</entry>
<value>102</value>
<description>Sanitär Meier</description>
</entry>
<value>103</value>
<description>Sanitär Schmidt</description>
</entry>
</lookUp>
</lookUpTables>

In diesem Beispiel ist in den System nur eine Lookup Tabelle vorhanden. Sie hat die Id 1 und den Namen "Kunden Nummern". In der Lookup Tabelle sind drei Werte ("101", "102" und "103") enthalten. Jeder dieser Werte hat auch eine Beschreibung.

<projects>

In diesem Abschnitt werden sowohl die Projekttypen als auch die vorhandenen Projekte ausgegeben.

<types>

In diesem Abschnitt werden die Projekttypen ausgegeben. Ein Unterabschnitt hiervon beginnt etwa so:

<type id='1'>
<name>Typ1</name>
<description></description>

Dadurch wir ein Projekttyp mit der Id 1, dem Namen "Typ1", sowie einer leeren Beschreibung definiert. Einem Projekt kann eine beliebige Anzahl Felder zugeordnet sein. Die Definition eines Feldes hat folgende Form:

<field id='1'>
<name>text1</name>
<datatype></datatype>
<formatString>[#*]</formatString>
<lookRefId>5</lookRefId>
<lookupMandatory>0</lookupMandatory>
<tooltip></tooltip>
<required>1</required>
<unique>1</unique>
</field>

Dadurch wird ein Feld mit der Id 1, dem Namen "text1", keinem Datentyp, dem Formatstring "\[#*\]", der lookRefId 5 und keinem Tooltip beschrieben. Boolsche Felder sind:

  • lookupMandatory
  • required
  • unique

Wie bei allen boolschen Felder müssen sie, wenn sie den Wert 0 beinhalten, nicht ausgegeben werden.

Da nicht alle Benutzer (bzw. Gruppen) Projekte jeden Typs anlegen dürfen, werden die Benutzer (bzw. Gruppen) welche das Recht (Create) haben, explizit aufgeführt. Dies geschieht in einem Abschnitt der Form:

<aclCREATE>
<user id='5' />
</aclCREATE>

Nach diesem Abschnitt hat lediglich der Benutzer mit der Id 5 das Recht ein Projekt mit diesem Typ zu erzeugen.

<project>

Der Abschnitt der Definition eines Projektes fängt folgendermaßen an:

<project id='4'>
<name>Dreibundstraße</name>
<description></description>
<typeId>1</typeId>

Dadurch wird ein Projekt beschrieben, welches die Id 4, den Namen "Dreibundstraße" und keine Beschreibung hat. Das Projekt ist vom Typ 1. Da zu jedem Projekt mehrere Felder gehören können, werden diese Werte einzeln ausgegeben. Dazu werden Abschnitte der Form

<field id='1'>
<value>123</value>
</field>

ausgegeben. Obiger Abschnitt beinhaltet, dass das Projekte mit der Id 4 und dem Typen 1 im Feld mit der Id 1 nur einen Wert ("123") gespeichert hat. Wenn einige Felder eines Projektes keine Werte enthalten, so müssen keine leeren Tags ausgegeben werden. Der entsprechende field Abschnitt kann in diesem Fall komplett entfallen.

Da nicht alle Benutzer (bzw. Gruppen) Dokumente zu jedem Projekt hinzufügen können, wird abschließend die Menge der Benutzer (bzw. Gruppen), die das notwendige Recht (write) besitzen ausgegeben. Dies geschieht in einem Abschnitt der Form:

<aclWRITE>
<user id='5' />
</aclWRITE>

Nach obigen Abschnitt hat lediglich der Benutzer mit der Id 5 das Recht zu dem Projekt Dokumente hinzuzufügen.

Format String

Definition:

  • i) Ein FS wird benutzt um einen String S zu validieren.
  • ii) S ist gültig, wenn er alle Anforderungen des Format Strings (FS) erfüllt.
  • iii) Ein FS setzt sich aus Zeichen (Z) und Metazeichen (MZ) zusammen.
  • iv) Zeichen müssen in S exakt auftauchen. Die Repräsentation eines MZ muss in S exakt auftauchen.
  • v) Metazeichen (MZ) stehen in eckigen Klammern [].
  • vi) MZ representieren unbekannte u.
  • vii) Es gibt 3 Arten von Metazeichen welche den Charakter von u festlegen: Ziffer (#), Buchstabe (X) und beliebig (?).
  • viii) u kann in einer definierten Anzahl n auftreten. Dafür muss das MZ n mal wiederholt werden.
  • ix) u kann beliebig oft auftreten Dafür muss auf das Metazeichen ein * folgen.
  • x) In eckigen Klammern steht jeweils nur ein Ausdruck, das sind entweder n identische MZ oder ein MZ und ein *.
  • xi) Jedes Zeichen hinter einem Backslash "\\" wird als Zeichen im Sinne des FormatStrings betrachtet. Ein Backslash (eckige Klammer) kann also wie folgt als Zeichen im FormatString definiert sein: \\ (\[) Zu beachten ist, dass \t und \n : t und n ergeben!

Beispiele:

  • gültige FS:
    • [##]-[##]-[####] -> 28-11-2005
    • abc+[X]-ef -> abc+w-ef
    • XYZ[X*] -> XYZasdnbaksjdlbasfdöjbfjb
    • [X*], der [##]. [?*] [####] ->Montag, der 24. Juni 2020
  • ungültige FS:
    • [#?]
    • [#*X]
    • [j]
    • [j::j]
    • [?X*]
    • [???*]

Silva Query Language (Siquel)

Main//Pyrus verfügt über eine eigene Query Language. Momentan wird diese ausschließlich zur Verwaltung des Rechtesystems verwendet. Die Syntax ist wie folgt:

command :== flush | alter
flush :== "flush privileges" ["of" subject | "of all projects"] [object]
alter :== {"grant" | "revoke" | "deny"} acls object "to" subject
acls :== | acl | acls acl
acl :== "read" | "write" | "delete" | "grant" | "revoke" | "native" | "manager" | "create"
object :== "on" {"document " id [" in class " id] | "class " id | "project " id | "project type " id}
subject :== "user " id | "group " id