Seit langem können bei uns die Mitarbeiter ihren Urlaub in SharePoint verwalten. Verwalten bedeutet, dass sie Urlaub eintragen, löschen und übersichtlich anschauen können. Außerdem sehen die Kollegen auf der Startseite übersichtlich, wann wer nicht da ist. Die Eingabemaske sieht wie folgt aus:
Und meine eigene Urlaubsübersicht sieht so aus (37,0 sind die Anzahl Tage, die mir dieses Jahr zur Verfügung stehen):
Und die rechte Leiste unserer Startseite sieht beispielsweise so aus (Ausschnitt):
Kurz zum technischen Hintergrund:
Wir verwenden dafür einen eigenen Inhaltstyp Urlaub. Daneben gibt es in unserem Kalender noch die Inhaltstypen ‘Krank’, ‘Außer Haus’ und ‘Im Haus’. Zum Erzeugen der Ausgabe (Spalte Titel), wie man sie auf der Startseite sieht, verwenden wir inzwischen einen Eventhandler, der diese zusammenbaut. Früher war dies ein berechnetes Feld. Wer also nicht programmieren will, muss dies nicht notwendigerweise.
Den Geschäftsprozess optimieren und Kosten senken:
Bisher war es so, dass die Buchhaltung am Ende des Monats die Daten in unser Lohnsystem manuell übernommen haben. Das benötigte ca. 1 Manntag. Wenn ihr euch jetzt fragt, ob das dann überhaupt Sinn macht bzw. sich lohnt, dann ist die Antwort ja, da
- Die Daten müssten so oder so im System erfasst werden
- Es entfallen die Anfragen der Mitarbeiter nach ihren verbleibenden Urlaubstagen
- Die Informationen auf der Startseite sind wichtig. Darüber hinaus gibt es noch einen Urlaubskalender, sodass sich z.B. in- und außerhalb der Abteilungen besser abgestimmt werden kann. Kurz: Der Informationsgewinn ist wichtig!
Um den Geschäftsprozess nun vollständig zu automatisieren, benötigten wir noch die Möglichkeit die Daten in unser Lohnsystem von GDI zu exportieren.
Dazu habe ich die Liste der Mitarbeiter, welche gefüllt ist mit Einträgen vom Inhaltstyp ‘heco Mitarbeiter’ um zwei Einträge erweitert:
- Export zu GDI (interner Feldname: ExportToGDI)
- Urlaub in Tagen (interner Feldname: HolidayInDays)
Beide Spalten sind vom Typ Ja/Nein. Das sieht dann so aus:
Die Spaltennamen sind selbsterklärend. Nun habe ich mit freundlicher Unterstützung von Olaf Didszun eine Kommandozeilenanwendung geschrieben, die anhand der gesetzten Eigenschaften in der Mitarbeiterliste die Daten aus dem Kalender ausliest und als CSV Datei exportiert (vgl. meinen Artikel dazu hier).
In dem ganzen Prozess gab es zwei besondere Herausforderungen:
- Monatsübergreifende Einträge
- Logik für Änderungen nach dem Export
Bei Punkt 1 wäre eine Option gewesen über Gültigkeitsprüfungen (ab SharePoint 2010 für Listen und Spalten out of the box möglich) solche Einträge zu unterbinden. Wir haben uns dagegen entschieden und haben die Logik so programmiert, dass das Programm solche Einträge erkennt und entsprechend monatsgenau abrechnet.
Zu Punkt 2: Das Problem ist, dass es möglich wäre, dass Mitarbeiter im Nachhinein Änderungen vornehmen, die im Vormonat liegen. Das stellt insofern ein Problem dar, als dass wir immer nur am letzten des Monats den Export vornehmen. Das Programm hat und sollte keine Logik dafür enthalten. Deswegen sind wir so Vorgegangen, dass wir eine SharePoint Gruppe angelegt haben, die sich “CalendarAdmins” nennt. Hier sind die Mitarbeiter der Buchhaltung enthalten. Nachdem ein Urlaubseintrag exportiert wurde, wird die Berechtigungsvererbung für das Element gestoppt und es werden alle Berechtigungsgruppen außer die ‘Besucher’ (die haben nur Lesezugriff) und die ‚CalendarAdmins’ entfernt. So ist gewährleistet, dass keine Änderungen nach einem Export mehr durchgeführt werden können, ohne über die die entsprechenden Stellen zu gehen. Der Code hierfür sieht so aus:
1: urlaubItem.BreakRoleInheritance(true);
2: SPGroup groupToRemove = urlaubItem.Web.AssociatedOwnerGroup;
3: urlaubItem.RoleAssignments.Remove(groupToRemove);
4: groupToRemove = urlaubItem.Web.AssociatedMemberGroup;
5: urlaubItem.RoleAssignments.Remove(groupToRemove);
6: urlaubItem.Update();
Uli Armbruster 
Kommentar verfassen