6

I did a migration from SharePoint on-premises 2013 to SharePoint online, using a third party tool, as follow:-

  1. The source on-premises site collection is a team site that have publishing features enabled and have 2 levels of sub sites. Also the build-in "Contribute" permission, have the "Manage Alerts - Manage alerts for all users of the Web site." permission unchecked as follow:- enter image description here

  2. To start the migration, I created a new online classic team site collection inside our office 365 and I migrated the on-premises site collection to it. And everything went fine. But today I were verifying the migrated online site, and I were comparing the permissions granted to the built-in permission levels, and I have noted that the migrated "Contribute" permission has the "Manage Alerts - Manage alerts for all users of the Web site." permission checked as follow:- enter image description here

so now i know that i can uncheck the "Manage Alerts - Manage alerts for all users of the Web site.", and have the permission check-boxes mimic the on-premises ones. but my question is how i can be sure that the migrated "Contribute" permission level is 100% identical to any "Contribute" permission level inside a brand new online site collection. for example can i do this:-

  1. create a new online classic team site collection >> which will have a built-in "Contribute" permission level >> run a PnP script to get all the permission it has.
  2. then run the same PnP script on the migrated site, and compare the 2 results.

now i know that i can access the Contribute permission level from the UI (as i did when i noticed the problem), but as i know that the UI permission check-boxes are not the lowest level permission, where a checkbox can have 2 or more lower level permissions underneath it. So my question is how i can get these lower level permissions for the "Contribute" permission level, to compare them inside the migrated site and inside a band new online site? Thanks.

7
  • Contact your 3rd party migration tool vendor. They'll be able to give you more details as to what is happening or perhaps it is even a bug in the tool.
    – user6024
    Feb 5, 2019 at 16:33
  • @TrevorSeward Yes i already contacted them, and they are investigating the issue, but i am asking how i can verify that the migrated contribute permission which i have mimic the built-in contribute permission for a brand new site. i need a check to retrieve all the PermisionKind for the contribute permission level.
    – John John
    Feb 5, 2019 at 23:11
  • 1
    I trying this for 1 hour and haven't found a solution for getting BasePermissions for SharePoint Online and I am not able to do it with CSOM or PnP modules, so honestly I dont know how to check these permissions... Feb 6, 2019 at 12:38
  • 1
    Yes, but you need to check all Root Sites. Feb 6, 2019 at 13:37
  • 1
    Honestly I dont know, I never collaborate with permissions and these problems. There should not be differences between SHP and SPO, but as I said I am not able to get PermissionKind and Base Permissions on SPO so I cannot check it. Maybe thats the reason why the migration was not successfull at this point, cause it didnt created permissions levels, they was created automatically with new site. Just check root site Permissions Definitions I think it should covered same like SHP. Feb 7, 2019 at 9:50

1 Answer 1

6
+25

I can show how to get this using JavaScript and REST:

$.ajax({
    url: _spPageContextInfo.webAbsoluteUrl + "/_api/web/RoleDefinitions/getByName('Contribute')",
    async: false,
    headers: {
        'accept': 'application/json;odata=nometadata'
    },
    complete: function (request) {
        var basePermissions = new SP.BasePermissions();
        basePermissions.initPropertiesFromJson(request.responseJSON.BasePermissions);

        var friendlyPermissions = [];
        for (var name in SP.PermissionKind.prototype) {
            if (name != "emptyMask") {
                var level = SP.PermissionKind.parse(name);
                if (basePermissions.has(level)) {
                    friendlyPermissions.push(name);
                }
            }
        }

        console.log("friendlyPermissions = " + JSON.stringify(friendlyPermissions, null, 4));
    },
    error: function (request) {
        console.log(JSON.stringify(request, null, 4));
    }
});

You can run this code in the browser developer tools console, and it will print the granular permissions to the console output. Just go to any classic page in your site, launch developer tools, and if jQuery isn't already loaded on the page run this once in the console:

var script = document.createElement('script');
script.type = 'text/javascript';
script.src = 'https://cdn.jsdelivr.net/npm/jq[email protected]/dist/jquery.js';
document.head.appendChild(script);

Then run the code above, and the console output should look like:

friendlyPermissions = [
    "viewListItems",
    "addListItems",
    "editListItems",
    "deleteListItems",
    "openItems",
    "viewVersions",
    "deleteVersions",
    "managePersonalViews",
    "viewFormPages",
    "open",
    "viewPages",
    "createSSCSite",
    "browseDirectories",
    "browseUserInfo",
    "addDelPrivateWebParts",
    "updatePersonalWebParts",
    "useClientIntegration",
    "useRemoteAPIs",
    "createAlerts",
    "editMyUserInfo"
    ]

And the results above are the OOB granular permissions for Contribute, at least on my SharePoint online tenant. I've only tested this code online, but it should work as far back as SharePoint 2013.

EDIT

If your not comfortable with developer tools, I've create a utility page that will do it (PermissionLevel2GranularPermissions.zip). The zip includes a single ASPX page that is actually a SharePoint wiki page, so you can drop it into any SharePoint document library and open it to use it. Choose a permission level from the drop down and click the Go Button, and it will put the granular permissions for the selected level in the text area.

I've commented it enough so hopefully you can see what it's doing. It's basically the same code as above, except first it calls "/_api/web/RoleDefinitions" to get the permission levels and populate the drop down. I have explicitly set the HTTP method to GET on both of the REST calls (that's actually the default in jQuery). In general, any write operations in REST need to use a request method other than GET (i.e. POST, PUT, MERGE, or DELETE), so setting the method to GET is enough to ensure you that it's not writing anything, just reading.

2
  • @Joe McShea thanks for the code, will try it. but can you please let me know if this code will modify any of the permission levels? or this script will only read the PermsionKind for the permission levels, so it is considered safe? in other words will the permission level after running this script mimic its setting before running the script? thanks again for ur help.
    – John John
    Feb 8, 2019 at 2:23
  • 1
    It will only read. It won't modify anything.
    – Joe McShea
    Feb 8, 2019 at 10:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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