Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

In a SharePoint Online (Office 365) environment we created a Sandboxed WebPart to put SPUsers in SPGroups. The SPGroup is created on rootlevel and has been given permissions on a subsite. This Subsite doesn't inherit permissions. We only use 1 SiteCollection.

We use the following code to add the User:

    SPUser user = SPContext.Current.Site.RootWeb.EnsureUser(*loginname*);
    Guid siteID = SPContext.Current.Site.ID;
    Guid webID = SPContext.Current.Web.ID;
    using (SPSite site = new SPSite(siteID))
    {
        using (SPWeb web = site.OpenWeb(webID))
        {
           try
           {
               web.AllowUnsafeUpdates = true;

               //Get the group for this web
               SPGroup oeGroup = web.Groups[*myGroupName*];
               if (oeGroup == null) return false;

               //Add the User to the OE Group
               oeGroup.AddUser(user);
               oeGroup.Update();

            }
            catch (Exception ex)
            {
                //Error Handling
            }
            finally
            {
                web.AllowUnsafeUpdates = false;
            }
        }
    }

When I execute this code the ID of the user has changed afterwards. The ID (Used to lookup the User from the UserInfoList) of the user before this action is 24. After this action it's 4066. I can see that the user is in the correct Group. When I delete the user manually (using the UI) and put it back manually the ID is back to 24.

I need the correct ID (24) to make different lookups to the User in the entire site. When performing the action manually the ID is kept 24. Can anyone help me with this?

share|improve this question
    
Hi, not sure why this happen but as a workaround maybe you can try to do it the other way, so add the group to the user ? msdn.microsoft.com/en-us/library/… –  Renzo Dec 9 '11 at 12:05
    
Thanks for the response. Unfortunately the SPGroupCollection.Add() method (msdn.microsoft.com/en-us/library/…) can only add a new group based on the parameters. I can't pass an existing SPGroup object to add to that Collection. –  Cas van Iersel Dec 9 '11 at 12:34
    
Update: The funny part of this story is that when I use the same code with JS Client Object Model it works as it should. –  Cas van Iersel Dec 13 '11 at 8:34

2 Answers 2

The code itself is rather strange. Why are you recreating already existent objects (I mean SPSite and SPWeb)? Based on my experience, this could lead to some rather weird heisenbugs, not to mention possible performance hit (especially if the procedure is called repeatedly from a loop).

Thuswise, the first thing I'd recommend is to avoid the needless creation of SharePoint objects and to get rid of the using's.

Next, as far as I know, site.RootWeb.EnsureUser and web.EnsureUser will provide the same result.

And the last thing: there are many different ways to get user by login. EnsureUser is only one of them. Why not to try to fetch the user directly from SPWeb.SiteUsers (or you can use SPWeb.AllUsers or SPWeb.Users - you can find their differences in MSDN). This approach garantees that user will not be created or recreated in any case. If this will not do for some reason, you can also try to query users from SPWeb.SiteUserInfoList.

So I suggest to try the following code (haven't tested it, so probably there are some typos):

string loginName = "*loginName*";
Guid site = SPContext.Current.Site;
Guid web = SPContext.Current.Web;
try
{
    web.AllowUnsafeUpdates = true;

    SPUser user = null;
    try
    {
        user = web.SiteUsers[loginName];
    }
    catch (SPException)
    {
        // User was not found. Let's try to create him
        user = web.EnsureUser(loginName);
    }

    //Get the group for this web
    SPGroup oeGroup = web.Groups["*myGroupName*"];
    if (oeGroup == null)
        return false;

    //Add the User to the OE Group
    oeGroup.AddUser(user);
    oeGroup.Update();

}
catch (Exception ex)
{
    //Error Handling
}
finally
{
    web.AllowUnsafeUpdates = false;
}
share|improve this answer

Thanks for all the replies everyone. At this point Microsoft marked it as bug and already patched it on the SharePoint Online environment.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.