Issue with AddPermission and auto-generated groups appearing

Sep 7, 2012 at 1:35 PM

I've put together the following demo: 

    operation: "AddPermission",
    async: false,
    objectName: "Alex Libby - Development",
    objectType: "Web",
    permissionIdentifier: "SP Test Group10",
    permissionType: "group",
    permissionMask: 1073741827,
    completefunc: function (xData, Status) {
      $(divId).append("<b>This is the output from the AddPermission operation:</b><br>");
      var strError = $(xData.responseXML).SPFilterNode('errorstring').text();
      if (Status ==  "success") {
        out = "Group has been successfully added.<hr>";
      } else if (Status == "error") {
        if(strError != "") {          
          out = "Error: " + strError + "<hr>";

- this appears to work perfectly, and adds a group to the site as expected. However, it is not granting the expected role type to that group, and adds in a "Auto-generated Permission Level f0..." role type instead?

I've used a GetRoleCollectionfromWeb example that I put together, to to get the required permissionMask that I am after, and have used it here; so as far as I am aware, the permissionMask ID is correct? It's not a role type that is available OOTB, but this shouldn't matter, should it? I've had a good look through all of the docs, but haven't managed to find anything that helps to explain what I'm doing wrong?



Sep 11, 2012 at 7:31 PM


I'm not sure one this one. I haven't done a lot with this particular operation. And you're sure that 1073741827 maps directly to one of your existing roles?


Sep 12, 2012 at 7:25 AM

Hi Marc,

Thanks for this - I did a copy and paste of the ID code from my GetRoleCollectionfromWeb demo, so I know the permissionMask does map to one of my existing roles (a copy of the relevant role is shown below):

0 ID 1073741827
1 Name EC Contribute
2 Description This is EC's contributor level access
3 Order 5
4 Hidden False
5 Type Contributor
6 BasePermissions ViewListItems, AddListItems, EditListItems, DeleteListItems, OpenItems, ViewVersions, DeleteVersions, ManagePersonalViews, ViewFormPages, Open, ViewPages, CreateSSCSite, BrowseDirectories, BrowseUserInfo, AddDelPrivateWebParts, UpdatePersonalWebParts

What I have noticed though is that on a demo I did for "GetRolesandPermissionsForSite", I see a similar issue there, where there is an autogenerated permission showing. However, the text that is rendered back shows this:

"Group Name: Auto-generated Permission Level dca67307-25aa-46bb-b12a-223ec944207b - Description: This permission level is automatically generated when the obsolete SPPermissionCollection class is used"

Could this be connected? Is this something that is coming from Microsoft's implementation of the web service, or is this coming from SPServices? I will do some more tests with OOTB box role levels, to see if this is something I am doing wrong...


Sep 13, 2012 at 1:06 PM

It looks like the purpose of the AddPermission operation is to create new roles and assign them to groups or users. Maybe you really want the Users and Groups Web Service? Maybe UserGroup.AddGroupToRole?


Sep 14, 2012 at 10:06 AM

Hi Marc,

I think I have found what may be the answer - it seems that this web service uses at least one method which is no longer supported by Microsoft: Permissions.Add(). I found it on a comment here: - I don't know if you want to add something to the SPServices site, to warn anyone still thinking of using it?

Thanks for your help though,


Sep 21, 2012 at 1:50 PM
Edited Feb 18, 2013 at 9:57 PM
Alex: I sort of have to rely on the fact that people using SPServices core will read the documentation for the operations they are using for the version of SharePoint they are using. That's why I provide the links into MSDN, though I admit that the majority of them are links to the 2007 docs. M.
Jan 19, 2015 at 5:03 PM
Hi Marc,
I tested UserGroup.AddUserToRole to give Read permissions to a user (notice I am not using AD user but one created with FBA):

    operation: "AddUserToRole",
    async: false,
    roleName: "Read",
    userLoginName: "i:0#.f|spsmembershipprovider|e25",
    userName: "E25",
    userEmail: "",
    userNotes: "User E-25",
    completefunc: function (xData, Status) {}

It worked perfectly, but I need to extend this operation to all my Sub Sites.
Is there a way to use this code form a Parent site in order to assign Read Permissions to all of its Sub Sites?
Jan 19, 2015 at 8:45 PM
Edited Jan 19, 2015 at 8:46 PM

I'm not sure you're using the right operation. It sounds like you actually want to add the user to a group that has read permissions for the Site Collection?

Jan 19, 2015 at 9:05 PM

This is my scenario,
a) I have a site called E, it has 163 sub sites called E1, E2, ... E163
b) I also have 163 users called E1, E2 ... E163
c) User E1 needs read permissions in sub site E1 only, user E2 needs read permissions in sub site E2 only, so on and so forth.

I started to manually assign read permissions but I quickly realized that it was going to take me a lot of time.
I want to be able to run a script from the parent site (E) and assign the permissions automatically.
I ran the script that I mention above, but I don't want to have to run that script in every site.

Hopefully I explained clearly and the solution is jumping in my nose.

Jan 19, 2015 at 9:11 PM

I think you should set up a permission group for each site that has Read permissions using AddGroup. Maybe E1 Readers, E2 Readers, etc. If you had created each site with its own permissions, you would have ended up with those permission groups.

Next give each group the permissions it needs, like E1 Readers get Read permissions on subsite E1 using AddPermission.

Then use AddUserToGroup to add E1 to E1 Readers, etc. This way, you can add other readers on an ad hoc basis, if needed, just by adding them to the appropriate group.

Always use permission groups unless you have a very good reason not to.