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.