Gestern kontaktierte mich ein Kunde, weil er es nicht schaffte, in einem SharePoint 2007 Kalender ein View einzurichten, welcher basierend auf dem Startdatum oder dem Enddatum gefiltert Einträge anzeigt. Die Site arbeitete bis vor ein paar Tagen noch mit dem SharePoint Portal Server 2003, wo er dies bisher ohne Probleme definieren konnte.

Ich habe dann das mal auf einem meiner SharePoint’s ohne Migrationshintergrund angeschaut. Völlig irritiert musste ich feststellen, dass sich so ein Filter wirklich nicht setzten lies. Damit starb meine anfängliche Vermutung, dass die SPS03-to-MOSS07 Migration das Problem war. Diverse Beiträge im Internet haben mir das nun auch bestätigt: In SharePoint 2007 Kalender kann man in einem View keinen Filter auf Start- oder/und End-Datum setzten. Eigentlich bin ich überrascht, dass ich über dieses Problem nicht schon eher angetroffen habe, ist dies ja nun wirklich nicht mein erstes SharePoint 2007 Projekt.

Variante 1: Calculated Fields

Nun gut, dem Kunde nützt kein Feedback, dass es nicht geht. Er will eine Lösung dafür – zumal es ja in der Vorgängerversion funktioniert hat. Im Internet findet man hierzu häufig die Lösung, dass man nun zwei weitere Felder hinzufügt. Beides sind calculated Fields, welche jeweils einfach die Werte der Originalfelder übernehmen (=[EndDate]). Diese berechneten Felder lassen sich dann bei der Filterdefinition verwenden.

Bei dieser Lösung berichten Andere aber davon, dass es Probleme mit der genauen Filterung von ganztägigen Ereignissen gibt. 

Variante 2: SharePoint Designer

Ich habe aber nun einen anderen Weg verfolgt: Da die gefragten Views in meinem Fall vom Setup her eher statisch sind (Filter und Feldauswahl ändern sich nicht), hab ich den View im SharePoint Designer 2007 editiert. Hier mein Vorgehen dazu:

1. Im besagten Kalender einen neuen View erstellen (oder sich den Namen des zu bearbeitenden Views merken). 
2. In diesem View einen Filter auf ein verfügbares Feld vom Typ DateTime setzen (z.B. “Erstellt”). 
3. Den Vergleichsoperator und den Vergleichswert setzt man schon analog dem Endergebnis. Da ich alle Ereignisse anzeigen will, welche in der Vergangenheit liegen, lautet meine Filterdefinition “Erstellt ist kleiner als [Heute]“.
4. Nun öffnet man den SharePoint Designer 2007, öffnet die entsprechende Site, geht zum Kalender und findet dort seinen View (ie. “Done.aspx”). Diesen öffent man nun in der Code- oder Split-Ansicht.
5. Beim KalenderwebPart findet man nun den View-HTML-Code (all das, was mit < und > grosszügig vermischt ist)
6. Jetzt sucht man am einfachsten nach “Where”. Der erste Treffer solle zu etwa diesem Abschnitt führen:

<Query><Where><Lt><FieldRef Name="Created"/><Value
Type="DateTime"><Today/></Value></Lt></Where></Query>

7. Wenn man nun einfach den FieldRef Name auf “EndDate” (oder “EventDate”) ändert und speichert, ist es das auch schon gewesen.

WICHTIG: Wenn man diesen View nun via SharePoint wieder ansehen geht, erscheint dort etwa folgendes:

Sprich, wenn ich den View irgendwie dort nun verändere, wird die Anpassung in der Filter-Field Selektion überschrieben und das Ergebnis ist wieder filterlos.

Bewertung der Varianten

Beide Varianten haben ihre Vor- und Nachteile. Bei der ersten Variante gibt es über die Contenttypes natürlich die Möglichkeit, dass man nicht jeden Kalender nachpflegen muss, sondern die neuen Felder einmal definiert und diese dann auf alle Kalender angewendet werden. Wenn Kalendereinträge bearbeitet werden, erscheinen diese berechneten Felder auch nicht. Aber es gibt einfach 2 Felder, welche nur zu Filterzwecken existieren und sonst keine Daseins-Berechtigung haben und die Probleme mit ganztägigen Ereignissen gilt es auch zu berücksichtigen.

Die SharePoint Designer-Variante ist dazu genau das Gegenteil: Es gibt keine weiteren Felder. Es kann aber auch nicht mit Contenttypes eine Vorlage editiert werden. Diese Anpassung muss für jeden Kalender gemacht werden. Auch ist hier die Gefahr gross, dass Benutzer diese Anpassung durch ein Bearbeiten des Views überschreiben.

Schlussendlich muss jeder situativ entscheiden, welche diese (mir bis heute bekannten) Varianten sich besser eignet.