Fehler bei Benutzer-Auswahlfeldern, die keine sind

Höchst erfreulich ist es, wenn man zum Feierabend am Freitag noch seltsame "Fehler" gelöst bekommt und dabei sogar noch etwas lernt:

Einer Liste haben wir über unsere Solution ein UserField hinzugefügt welches wir per FeatureReceiver auf eine - vorher in einem anderen FeatureReceiver generierte - Benutzergruppe zeigen lassen um die Suche im Katalog auf diese Gruppe einzuschränken.

Das hat auch wunderbar funktioniert... Wenn ich als SiteCollection-Administrator ein neues Element innerhalb dieser Liste erstellen möchte, sieht das Formular aus, wie erwartet. Als anderer User, egal, welche Rolle (ausser dem SiteCollection-Administrator) er innehat, erscheint die "Fehlermeldung": "Das Steuerelement ist nicht verfügbar, da Sie nicht über die erforderlichen Berechtigungen verfügen."

Googeln hat leider nichts ergeben, auch das Herumspielen mit den Berechtigungen des Users oder der Gruppe, in der er Mitglied ist, blieb erfolglos.

Dann aber fiel der Groschen, als ich mich an ein früheres SharePoint-Projekt von uns erinnerte. Düster erinnerte ich mich, dort mal eine Einstellung gesehen zu haben, die schaltet, wer Mitgliedschaften einer Gruppe anzeigen darf. Und siehe da, nachdem ich über die Oberfläche die Einstellung "Jeder" vornahm, hat es plötzlich funktioniert.

Rot umrandet im unteren Bild: die "Fehlermeldung"
Grün umrandet im unteren Bild: der Soll-Zustand des Auswahlfeldes, nachdem "Jeder" gewählt wurde




Das nächste Bild zeigt die Einstellung in den Gruppeneinstellungen:



Nun galt es noch, das ganze programmatisch umzusetzen, was in drei Zeilen erledigt war:

SPGroup spGroup = siteGroups[groupTitle];
spGroup.OnlyAllowMembersViewMembership = false;
spGroup.Update();

spGroup.OnlyAllowMembersViewMembership = true; würde bewirken, dass die Einstellung "Gruppenmitglieder" gewählt wird.

Fazit: Manchmal sind Fehler gar keine Fehler im herkömmlichen Sinne. Hier muss ich wohl noch etwas mehr in die SharePoint-Denke hineinkommen. ;-)

Beschreibungen der Attribute der Solution-Bestandteile

Der Blog von André Vala bietet sehr sehr nützliche Informationen zu den einzelnen Teilen einer Solution, z.B. alles über ListInstanzen, ListTemplate-Features, ContentType-Features, SiteColumn-Features inklusive einer Beschreibung der wichtigen XML-Tag-Attribute.

List Instance Features
List Template Features
Site Content Type Features
Site Column Features

SharePoint Bekanntheit

Ich bin die letzten zwei Tage auf einer Messe für Medizintechnik gewesen und habe mich dort mit einigen Leuten aus diese Branche unterhalten.

Interessant ist, dass das Thema Microsoft SharePoint dort scheinbar noch gar nicht angekommen ist, aber einige Gesprächspartner Anforderungen und Szenarien beschrieben haben, die in meinen Augen förmlich nach einer SharePointlösung geschrien haben. Wobei man hier natürlich noch weiter ins Detail hätte gehen müssen.

Anforderungen die genannt worden sind:

• Templatemanagement
• Dokumenten Versionierung
• Workflowunterstützung
• Erzwungene Vergabe von Metadaten
• Abkehr von Ordnerstrukturen

Ich denke, dass in diesem Bereich noch die Chance besteht auch mit einfachen Lösungen den Arbeitsablauf von vielen Mitarbeitern zu verbessern: Ich bin gespannt, ob sich dort bald konkretere Ansatzpunkte auftun…

Best Practices: Using Disposable Windows SharePoint Services Objects

Neugierig geworden ob eines Artikels, der im WSS SDK öfter mal erwähnt wird, stieß ich eine Google-Suche an, die mir als ersten Eintrag folgenden interessanten Link zum Thema Good Coding Practice in der MSDN lieferte: *click*

Nachtrag: Ich habe den Link nun auch zu den 'wichtigen Links' in der Navigation hinzugefügt.

ItemUpdating und Afterproperties!!

Gegeben sei ein Eventhandler, welcher die Veränderung eines bestimmten Feldwertes erkennt und darauf reagieren kann.

Den alten Wert bekommt man mit properties.ListItem["FieldName"]

Den neuen Wert bekommt man theoretisch mit properties.AfterProperties["FieldName"]

Praktisch liefert das aber immer null für den neuen Wert. Man kommt aber trotzdem an den neunen Wert, indem man mit dem internen Namen des Feldes arbeitet:

properties.AfterProperties[spcurrentitem.Fields["Projektnummer"].InternalName]

Warum das so ist, erschließt sich mir leider nicht.....

Den Defaultvalue von DateTime-Feldern ändern

Prinzipiell ist es relativ einfach den Defaultvalue von SPField-Objekten zu setzen. Wunderlich wird es allerdings, wenn z.B. der Wert "07.07.2008" aus einem DateTime-Feld in ein anderes kopiert werden soll, als neuer DefaultWert aber stattdessen dann "07.07.1907" auftaucht.

Nach etwas Herumsucherei bin ich auf diesen Blogeintrag gestoßen *click* der uns verrät, dass SharePoint das "Coordinated Universal Time"-Format (UTC) bevorzugt, also Datumswerte in der Form 'yyyy-mm-ddThh:mm:ssZ'.

Das kann ganz einfach durch die Methode .ToString("u") erzielt werden, welches ein Datum in das kulturunabhängige UTC-Format umwandelt.

Der Code des konkreten Falls sieht demnach so aus:

SPFieldDateTime abgabeDatum = (SPFieldDateTime)positionList.Fields["Abgabedatum"];
abgabeDatum.DefaultValue = ((DateTime)properties.ListItem["Abgabedatum"]).ToString("u");
abgabeDatum.Update();