10 Dinge, die Sie uns hätten sagen sollen (1. Teil)

Ich habe gerade einen sehr guten Artikel gefunden, den ich hier auch verlinken möchte. Klick

Titel: 10 Things You Wish they Told You-Part 1

Thema: welche Eigenheiten hat Microsoft SharePoint 2007 und was wird dem geneigten User in der Produktbeschreibung NICHT gesagt?

Probleme beim Updaten von SPFieldLookup-Objekten

Ein Lookup-Feld programmatisch auf eine Liste verlinken ist ein Kinderspiel: einfach die Attribute LookupList mit der GUID der auswählbaren Liste und LookupWebId mit der jeweiligen WebID belegen. Fertig!...

Von wegen! Das ganze funktioniert nämlich nur, solange der aktuelle Benutzer Site Collection Administrator ist.

Wird das von einem User, der nicht Site Collection Administrator ist, angestoßen, kracht es und der Aufruf

spFieldLookup.LookupWebId = spRootWeb.ID;

wirft eine System.UnauthorizedAccessException: Access is denied, bzw. Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)

Eine Lösung für das Problem bietet das SDK durch den Einsatz der Methode SPSecurity.RunWithElevatedPrivileges, der ein delegate übergeben werden kann in dem dann der jeweilige Code ausgeführt wird.

Laut SDK wird die spezifizierte Methode mit FULL CONTROL-Rechten ausgeführt, egal, ob der User diese Rechte besitzt oder nicht.

Ein Beispiel dafür findet sich in der MSDN: *click*

Bei uns sieht das dann in etwa so aus (ich habe ein paar Code-Zeilen der Übersichtlichkeit halber ausgelassen):

SPSecurity.RunWithElevatedPrivileges(delegate()
               {
                       SPWeb site = (SPWeb)properties.Feature.Parent;
                       SPSite siteColl = site.Site;

                       // get current site
                       using (SPSite elevatedSiteColl = new SPSite(siteColl.ID))
                       {
                           // get current web
                           using (SPWeb spCurrentWeb = elevatedSiteColl.OpenWeb(site.ID))
                           {
                               // get rootweb from this web's parent site
                               using (SPWeb spRootWeb = (SPWeb)spCurrentWeb.Site.RootWeb)
                               {
                                           ...anderer code, der z.b. die liste, auf die das lookup-feld referenzieren soll, einlist...

                                           SPFieldLookup spFieldLookup = (SPFieldLookup)spList.Fields.GetFieldByInternalName(lookupInfo.FieldInternalName);
                                           spFieldLookup.LookupWebId = spRootWeb.ID;
                                           spFieldLookup.LookupList = listGuid.ToString();
                                           spFieldLookup.Update();
                                   }
                               }
                           }
                       }
               });

Ganz wichtig ist, dass die aktuelle SiteCollection, neu instanziiert wird. Ansonsten wird das SPSite-Objekt des aktuellen Users benutzt was ja ausserhalb des SPSecurity.RunWithElevatedPrivileges-Kontexted generiert wurde und daher keine Berechtigung hat, das Lookup-Feld zu verändern.

Meiner Meinung nach sollte diese Methode wirklich nur an Stellen benutzt werden, an denen es keine Alternative gibt, da sie das Sicherheitskonzept völlig aushebelt und dem Code, der vom aktuellen Benutzer ausgeführt wird, viele Rechte gewährt...

Site Provisioning Reihenfolge

Eine schnelle Suche nach einer Auflistung, in welcher Reihenfolge Einträge der onet.xml abgearbeitet werden, brachte mich auf folgenden Blog-Eintrag der MSDN: *click*

Ich habe den Eintrag mal ins Deutsche übersetzt:

SharePoint stellt in dieser Reihenfolge bereit:

1. die globale onet.xml
2. in der onet.xml definierte SiteScope-Features in der Reihenfolge, wie sie angegeben sind
3. Stapled Features auf SiteScope-Ebene in "zufälliger" Reihenfolge
4. in der onet.xml definierte WebScope-Features in der Reihenfolge, wie sie angegeben sind
5. Stapled Features auf WebScope-Ebene in "zufälliger" Reihenfolge
6. in der onet.xml definierte List Instanzen
7. in der onet.xml definierte Modules

Das bedeutet:

1. SiteFeatures sollten niemals von etwas abhängig sein, was durch ein WebFeature bereitgestellt wurde. Da WebFeatures immer nach SiteFeatures ausgewertet werden, kann ein SiteFeature nicht auf eine Resource angewiesen sein, die in einem WebFeature bereitgestellt wird.
2. Features können nicht von Listen oder Dateien abhängig sein, die über die onet.xml bereitgestellt werden. Features werden vor den Dateien und Modulen, die in der onet.xml enthalten sind, verarbeitet. Trotzdem können List Instanzen und Dateien, die in der onet.xml definiert sind, Abhängigkeiten auf sich in Features befindenden List Definitionen oder List Instanzen enthalten.
3. In der onet.xml oder in WebFeatures, die sich innerhalb des -Tags befinden, definierte List Instanzen und Module sollten niemals Abhängigkeiten auf "Stapled Features" enthalten. "Stapled Features" sind flüchtig und es kann sein, dass sie nicht im Stapel abgearbeitet werden wenn der Administrator die Konfiguration so einstellt.
   

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.