Link Empfehlung

Vgl. Consultants Digest

… ich habe schon im letzten Post vom Blog von Natalya Voskresenskaya gesprochen und habe mich jetzt noch ein wenig mehr auf dem Blog rumgetrieben und finde ihn sehr empfehlenswert. Ich nehme ihn deshalb in meine Blogroll auf. Der Blog ist auch hier zu finden. Einfach mal vorbeischauen, lohnt sich!

SharePoint implementation best practices

ich habe gerade einen sehr guten Artikel zum Thema "SharePoint implementation best practices" auf TechTarget gelesen, in dem Natalya Voskresenskaya vom Sharepoint for Squirrel Blog einige sehr richtige Aussagen über die Implememtierung von Sharepoint in den meisten Firmen macht.
Besonders den Punkt mit der IT Abteilung und dem Business und User Fokus finde ich treffend. Was sind Ihrer Ansicht nach die Dinge, die man vor der Implementierung herausfinden muss? Folgende, die ich alle nur zu 100% unterstützen kann:

• How groups collaborate with one another.
• What applications they are using in their daily routine. This will help you determine information sources, legacy systems and line-of-business applications.
• The intended audience of the information that is produced.
• Where internal activities overlap between groups.
• Everyday challenges. (By determining this, you will identify your customer's pain points.)
• Auditing requirements.

Alles in allem ein sehr gelungener Artikel.

International SharePoint Professionals Association

Vor kurzem ist die International SharePoint Professionals Association online gegangen. Ich habe mich heute mal auf ihrer Seite *click* umgesehen. Interessant finde ich den Ansatz mit den regionalen Evangelisten (lustiger Begriff). Für Deutschland ist wie zu erwarten war Michale Greth *click* ins Rennen gegangen. Ich werde die Seite in Zukunft häufiger besuchen und bin gespannt, wie sich dieser Ansatz weiter entwickeln wird. Vielleicht schließe ich mich auch einer SharePoint Gruppe an.

...Merkwürdigkeiten...

...obwohl wir an dem System in den relvanten Teilen nichts geändert haben, haben heute morgen einige der Nintex Workflow nicht mehr funktioniert. Nach dem ich mir die Workflows im Detail angeschaut habe und alle Einzelheiten geprüft habe, aber keinen Fehler gefunden habe, habe ich sie einfach noch ein mal neu publiziert. Und siehe da, es funktioniert...

Das scheint eine dieser SharePoint Besonderheiten zu sein...

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.