Ein gutes Intranet soll so konzipiert sein, dass zum einen alle relevante Informationen mit wenig Aufwand direkt verwaltet und angezeigt werden können und das zum anderen den Mitarbeiter beim Lösen der täglichen Aufgaben weiterhilft.
Eines der wichtigsten Elemente jeder Organisation ist eine durchdachte und strukturierte Dokumentenverwaltung. Diese Dokumente können sowohl Anfragen von Kunden, Angebotsvorlagen, als auch Anforderungsdokumente sein und müssen jederzeit verfügbar und ersichtlich sein. Je nach Position des Mitarbeiters darf dieser unterschiedliche Dokumente sehen. Als Beispiel benötigen die Entwickler nur die projektrelevanten Daten wie z.B. Anforderungsdokumente oder Featurebeschreibungen. Es ist also wichtig, Dokumente auf Gruppenebene und auf Benutzerebene freischalten zu könnnen.
Die Dokumente sollten zentral verwaltbar sein (Das Upload Modul ist dazu nicht immer von Vorteil!). Wenn man ein Dokument an mehreren Nodes als Anhang "verlinkt" und es dann bearbeitet, sollte es ja eigentlich auch an allen anderen Stellen aktualisiert werden. Dokumente sollte man also nicht duplizieren (wie man es beim Upload Modul tun würde) sondern zentral verwalten und verlinken, wie es in einem typischen Asset-Management-System der Fall wäre.
Wenn Mitarbeiter die Dokumente bearbeiten dürfen, wäre auch eine Versionierung sehr hilfreich. So können Änderungen in Dokumenten nachvollzogen werden (wichtig haupsächlich für Anforderungsdokumente) und bei Bedarf vorherige Versionen wiederhergestellt werden. Dazu genügt es nicht die Durpal-eigenen Revisionen anzuschalten da die Dateien ja nicht versioniert werden sondern nur die Inhalte der Nodes.
Damit man den Überblick über alle Dokumente behält ist es hilfreich sich ein System zu entwickeln, dass sowohl eine Kategorisierung zur groben Sortierung als auch eine Verschlagwortung für detaillierte Einteilungen besitzt.
Wie baut man ein solches System in Drupal auf?
Bei der Planung einer Dokumentenverwaltung muss man folgende Punkte beachten:
- Eine Versionierung der Dokumente sollte möglich sein, damit Änderungen direkt nach verfolgt werden können.
- Nicht jeder Mitarbeiter muss unbedingt alle Dokumente sehen und somit ist ein Rechtesystem notwendig.
- Dokumente solllen zentral verwaltet werden und jederzeit verlinkbar sein
Dies führt direkt zu der Entscheidung, dass jedes Dokument ein eigener Node sein muss. Auf den ersten Blick vielleicht etwas als Overhead betrachtet, aber dies bietet viele weitere Möglichkeiten zur Umsetzung der oben genannten Anforderungen. Natürlich kann man den Body zu einem Dokument Node "abschalten". Wir brauchen Ihn nicht, das die Inhalte ja im eigentlichen Dokument vorhanden sind. Dieser Node hat ein Filefield zum Upload des Dokuments, eine Kategorieauswahl und ein Taxonomiefeld zur freien Zuweisung von Schlagwörtern. Natürlich kann man für Notizen die Kommentarfunktion aktivieren, Subscriptions verwenden und weitere statische Kategorien einfügen. Dank der Flexibilität der Nodes für die wir uns als "Container" der Dokumente und Dateien entschieden haben, sind Erweiterungen mit Views, CCK und Co. keine Grenzen gesetzt.
Die Versionierung der Dateien erfolgt über GIT. Es kann jederzeit vorkommen, dass ein Dokument geändert wurde, weil sich z.B. die Anforderungen ändern. Damit nachverfolgt werden kann, wer diese Änderungen durchgeführt hat, wird ein System zur Versionierung der Dokumente bereitgestellt.
Damit die Dokumente immer automatisch versioniert werden, wird in dem Files-Ordner, in dem die Dateien des Uploadfields der Nodes liegen, ein GIT Repository erstellt. Dieses Repository wird immer dann mit GIT committed, wenn ein Node des Types "document" gespeichert wird. Das haben wir mit dem PHP-Befehl
System('git commit -a');
im hook_nodeapi umgesetzt, was toll funktioniert. Wenn man möchte, kann man dann das Modul Git Browser verwenden um das GIT Repository der Dokumente zu durchstöbern. Natürlich ist eine Versionskontrolle hauptsächlich für Textdokumente gedacht. Divs sind bei Worddokumenten dannn nicht sonderlich gut möglich, eine Version zurücksetzen lassen diese sich aber auch allemal, was sehr von Vorteil ist.
Anhand der Kategorien wird das Rechtesystem implementiert. Unsere Mitarbeiter besitzen unterschiedliche Rollen. Ein Entwickler muss z.B. nicht die Verträge mit dem Kunden sehen und somit können die Dokumente mit der Kategorie "Verträge" nur von den dafür zuständigen Mitarbeitern gesehen werden (z.B. der Geschäftsführer oder der Projektleiter mit einer spezifischen Rolle). Diese Funktion zur Überprüfung der Rechte anhand der Kategorien wurde manuell programmiert, damit es zu keinen Konflikten mit unserem Projektplaner im Storm kommt. Wir hatten dazu auch die Content Access Module eingesetzt und leider kam es dabei immer wieder zu Konflikten mit dem internen Rechtesystem von Storm.
Damit ein neues Dokument im CRM eingefügt werden kann, wurden Nodereferenzfelder in die bestehenden Inhaltstypen eingefügt. Wird also in einem Kundenkontakt ein Dokument eingefügt, erfolgt dies über eine Verlinkung durch eine Nodereferenz. Dabei ist das Modul Node Relationships besonders zu empfehlen, da es über seine "Create and Reference" Funktion eine direkte Erstellung von Dokumentennodes ermöglicht. So wird bei einer Anfrage z.B. direkt ein Dokument verlinkt und als Node in der Dokumentenverwaltung abgelegt und zugleich mit GIT versioniert. Da wir zuvor bereits Dokumente mit dem Filefield an Nodes angehängt hatten, wurde in einem Updatescript etwas Refactoring betrieben, welches die per Filefield angehängten Dateien in Nodes konvertiert und dann diese Nodes per nodereference verlinkt. Auch das klappte problemlos mit etwas Programmierung.
Nun hat man die Dateien verlinkt. Zum Bearbeiten muss man jedoch in das Dateisystem des Servers wechseln. Das ist jedoch sehr hinderlich und kostet einiges an Zeit. So hatten wir die Idee, ein Java-Applet zu schreiben, welches die Dateien lokal mit dem Entsprechenden Programm öffnet. Das Applet ist signiert und hat somit auch Zugriff auf den Lokalen PC, voraussgesetzt, das dieser PC Lese- und Shreibzugriff auf den Pfad der Datei hat. Da nach dem Bearbeitungsvorgang über diesen Weg kein Node gespeichert wird, wird die veränderte Datei auch nicht automatisch ins GIT Repository committed. Das übernimmt dann ein Cronjob, der das Repository nochmal jede Stunde mit dem oben genannten Befehl git commit -a eincheckt.
Ein weiterer Vorteil dieser Drupal Dokumentenverwaltung iist die Verwaltung von bestehenden Dokumenten. Dadurch, dass jedes Dokument ein eigener Node ist, kann durch ein View gezielt nach Dokumenten gesucht werden. Dazu stehen einem mehrere Möglichkeiten zur Verfügung:
- Die Kategorie als hervorgehobener Auswahlfilter
- Die Taxonomie in Form eines Suchfelds
- Die Nodereferenzen auf die bestehenden Vorgänge oder Projekte
Auf den ersten Blick mag man sich fragen, wieso man nicht einfach nur einen "Dateianhang" in die bestehenden Inhaltstypen einfügt, doch mit der Zeit ergeben sich durch dieses System eine Vielzahl an Vorteilen die wir heute nicht mehr missen wollten.
Sind Sie ebenfalls an unserer Leistung im Bereich Intranet und CRM Entwicklung interessiert so kontaktieren Sie uns gerne jederzeit.
Kommentar hinzufügen