Jag har byggt en lösning åt en kund som systematiserar ett par av deras interna processer, lösningen är baserad på SharePoint och WF workflows byggda i Visual Studio. I samband med att de testade systemet hittade de ett fel som jag inte riktigt förstod.

De ändrade systemkonfigurationen så att en viss sorts händelser i systemet som genererar en uppgift (task) skulle tilldelas en nyskapad SharePoint grupp, alltså en grupp som ännu inte hade använts till något. Felet de upptäckte var att efter en IISRESET så kunde in gruppen inte hittas när dess medlemmar skulle enumereras, men andra gången gruppen skulle användes så fanns den där.

Först trodde jag att det var ett testfel hos dem, men sedan så lyckades jag (till min förvåning) att återskapa felet i min utvecklingsmiljö. När jag debuggade koden så fanns inte gruppen första gången, men andra gången så var den där.

Men då slog det mig att jag i den hjälpmetod som genererade felet använde mig av SPWeb.Groups istället för SPWeb.SiteGroups! På alla andra ställen i koden använde jag SiteGroups, och då fanns alltid gruppen där, men just här använde jag Groups och då saknades den. Aha, ett samband framträder och jag minns vad som skiljer mellan Groups och SiteGroups: Groups innehåller grupper som har minst en rättighet i en SPWeb medans SiteGroups innehåller alla grupper (oavsett om de har rättigheter eller inte).

En snabb ändring till SiteGroups och allt fungerade!

Det som hände var att första gången min rutin användes så hade gruppen inga rättigheter (och finns då inte med i SPWeb.Groups), men längre ner i flödet så tilldelas en uppgift (task) till gruppen och då får den en rättighet i webben. Så nästa gång rutinen körs så har gruppen rättigheter och SPWeb.Groups ger tillbaka ett svar som innehåller gruppen.

En generell regel är alltså att man bör använda SPWeb.SiteGroups när man ska slå upp grupper, om man inte är specifikt intresserad av grupper som har minst en rättighet på webben.