permissions – NateChamberlain.com

September 9, 2020September 9, 2020

Create a custom permission level in SharePoint

I’m often asked for a way to modify permissions beyond what’s available out of the box, but without using workflows.

There are settings that allow item-level permissions in lists (List Settings > Advanced Settings > Item-level Permissions) so that users can only see and/or edit their own items, but this may not solve your need. If so, ta-da! If not, keep reading.

In this post, I’ll cover one solution in which we create a custom permission level at the site level that we’ll assign to a group on a specific list’s permissions. This new, custom permission level will be the same as the Contribute level (out of the box) but removes the ability for users to delete items or versions.

Creating a custom permission level involves a couple main steps:

Create the new permission level.
Change permissions on the list so that the group of users who should have the new permission level are assigned the new permission level.

Create the new, custom permission level

1. Go to Site Settings

2. Under Users and Permissions, select Site permissions

3. Click Permission Levels

4. You could click Add a Permission Level but I typically prefer to copy an existing level (like Contribute) and just make a couple small changes. For this tutorial, I’m going to select Contribute.

If copying a level, scroll down to the bottom after selecting a level and click Copy Permission Level.

5. Name and describe the new permission level, then check and uncheck as needed to create the permission level desired. In my example, I want to copy Contribute, but remove the delete ability so I’ve unchecked the two options involving deletion of items and versions.

6. Scroll down and click Create.

Change permissions on the list

Now we need to assign our new permission level to users on the list for which we’re preventing deletion.

1. Go to List Settings.

2. Under Permissions and Management, select Permissions for this list.

3. Select the box next to the name of the group for which you’re modifying permissions.

4. Click Edit User Permissions from the top ribbon menu.

5. Uncheck the current permission level assigned to the group, and check the new custom permission level.

6. Click OK.

September 9, 2020September 9, 2020

Change the email address used for Access Requests on all SharePoint sites and subsites in a web app using PowerShell

Perhaps you’ve changed SharePoint administrators or a site owner or two recently. Where are the SharePoint site Access Requests they were receiving now going?

This post covers two PowerShell methods of updating the email address used across all sites in bulk:

Replace the email address used on ALL sites, no exceptions (reset all requests throughout the web app to be sent to one address)
Change all instances of a specific address to a replacement across ALL sites (i.e. replace the former site owner’s address used in 12 sites’ Access Request Settings with the new site owner’s address)

The second method is particularly nice because it eliminates any guesswork involved in wondering where the former admin/owner may have been listed as the recipient.

Replace the email address used on ALL sites

To modify the email address used for all SharePoint sites and subsites in a web app, run the PowerShell script below from a SharePoint server. You’ll need to replace the $webapp and $requestemail values at the top.

Caution: This action cannot be undone. It replaces the Access Request email on all sites and subsites.

Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue 
  
$webapp = Get-SPWebApplication https://sharepoint.contoso.com  
$requestemail = "new-request-recipient@demo.com"   
  
foreach($site in $webapp.Sites)  
{  
   foreach($web in $site.AllWebs)  
   {  
     $url = $web.url  
     Write-host "Checking "$url  
     if (!$web.HasUniquePerm)  
     {  
            Write-Host "Site inherits Access Request settings from parent." -ForegroundColor Yellow  
     }  
     else  
     {  
       if($web.RequestAccessEnabled)  
       {  
            Write-Host "Site utilizes Access Requests."   
            $web.RequestAccessEmail = $requestemail  
            $web.Update()  
            Write-Host "Email changed to " $requestemail -ForegroundColor Green
        }  
            else  
      {  
            Write-Host "Site is not utilizing Access Requests." -ForegroundColor Yellow  
      }  
   }  }
}

Replace all instances of a specific user across all sites in the web app

Perhaps a particular individual left their site owner/admin role and you just want to replace any instance of THAT user in Access Request settings throughout the web app. In that case use the following script instead (updating the three parameters at the top, $webapp, $oldrequestemail, and $newrequestemail):

Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue 

$webapp = Get-SPWebApplication https://sharepoint.contoso.com
$oldrequestemail = "old-request-email@contoso.com"  
$newrequestemail = "new-request-email@contoso.com"   

foreach($site in $webapp.Sites)  
{  
   foreach($web in $site.AllWebs)  
   {  
        $url = $web.url  
          Write-host "Checking "$url  
          if (!$web.HasUniquePerm)  
          {  
                 Write-Host "Site inherits Access Request settings from parent." -ForegroundColor Yellow  
     }  
          else  
     {  
            if($web.RequestAccessEnabled)  
                   {  
                   if($web.RequestAccessEmail -eq $oldrequestemail)
            {
            Write-Host "Site utilizes Access Requests sent to old email ("$web.RequestAccessEmail")." -ForegroundColor Red
            $web.RequestAccessEmail = $newrequestemail  
            $web.Update()  
            Write-Host "Email changed to" $newrequestemail -ForegroundColor Green
        }  
                    else 
               {            
                    Write-Host "Email ("$web.RequestAccessEmail") does not match old email address. No change made." -ForegroundColor Yellow
               }}
            else  
      {  
            Write-Host "Site is not utilizing Access Requests." -ForegroundColor Yellow  
      }  

   }  
   }  
   }

Note: If you’ve changed the Access Request recipient and the new person is receiving a “Sorry, this site hasn’t been shared with you” error when attempting to approve requests, check out this post for help.

Credit and gratitude to Ketak Bhalsing and his post on bulk-updating for pointing me in the right direction on this one.

September 2, 2020September 2, 2020

Solution: SharePoint site owner with full control unable to approve access requests; site is missing a default members group

In this post I’ll cover two symptoms commonly seen when subsites evolve from inheriting permissions (using existing groups) to being given unique permissions (having their own groups at the site’s level).

Symptoms

A site owner with full control gets “Sorry, this site hasn’t been shared with you” when trying to approve access requests.
When reviewing Access Request Settings, a user or owner sees the message “Members cannot share this site because this site is missing a default members group.”

Cause

Chances are the site was never set up with default, unique permissions groups. Perhaps the creator of the site chose to inherit permissions from the parent (using existing groups from a hierarchical level higher than the new site), then later decided to manually build out groups that resemble the traditional visitors, members, and owners groups at the new site’s level. Or perhaps the default groups were deleted. Either way, the following solution should set it straight:

Solution

We need to either officially designate or build new default groups for the site, using the same dialog you see when creating a new site. Since we can’t “reconfigure” the site with a wizard, we need to manipulate the site’s URL a bit to get to the configuration screen we’re looking for.

Add “_layouts/15/permsetup.aspx” to the end of the site URL. For example, it may resemble sharepoint.contoso.com/sites/ABC/EA/_layouts/15/permsetup.aspx. This takes you to the permissions setup page.

IF YOU HAVE GROUPS YOU WANT TO SET AS THE DEFAULTS

Perhaps after site creation, you created groups intended to be used like the visitors, members, and owners groups. Go to your site’s _layouts/15/permsetup.aspx page and simply:

Leave “Use an existing group” selected, and change the dropdown for each to the groups that were created and intended to be the new defaults. Click OK when finished. This will make them “official.”

IF YOU DON’T HAVE GROUPS YOU WANT TO SET AS DEFAULT

Change “Use an existing group” to “Create a new group” for at least the Members and Owners options. Here you can add the appropriate persons to each group, or add them at a later time via Site Settings > Site Permissions. Be sure to add your owners (approvers/permissions managers) to the new owner group.

August 10, 2020February 21, 2022

Read vs Restricted Read vs View Only Permission in SharePoint

I recently had a SharePoint admin assigning Restricted Read permissions to users and out of curiosity wanted to refresh my memory on what distinguishes Read from Restricted Read. While I was at it, I took a look at View Only as well.

Basically, Read and View Only are nearly identical. The only distinction is that Read can download documents, while View Only can only open them and view them in the browser.

Restricted Read is minimally permissive, and doesn’t include the ability to create alerts, view versions, download, or exercise some site abilities (see table below for specifics).

You’ll also notice in the table below that View Only can Open, but not Open Items like Read. According to documentation, the difference is this:

Open Items (list permission): “View the source of documents with server-side file handlers.” Requires Open permission:
Open (site permission): “Enables users to open a website, list, or folder to access items inside that container.”

In the table below, list permissions are blue and site permissions are red. Download Documents is not a listed permission, but added for clarity to distinguish Read and View Only.

	View Only	Restricted Read	Read
Browse User Information	X		X
Create Alerts	X		X
Download Documents			X
Open	X	X	X
Open Items		X	X
Use Client Integration Features	X		X
Use Remote Interfaces	X		X
Use Self Service Site Creation	X		X
View Application Pages	X		X
View Items	X	X	X
View Pages	X	X	X
View Versions	X		X

Permissions comparison matrix for read, restricted read, and view only in SharePoint.

Source: https://docs.microsoft.com/en-us/sharepoint/sites/user-permissions-and-permission-levels

December 16, 2019December 16, 2019

Creating a Team from an existing O365 group

O365 groups make up the sun in the O365 solar system. And every Microsoft Teams team (planet?) must have an O365 group to exist. You’ll also use O365 groups for group email and calendars, defining permissions for private Stream channels, collaborating with group members in Planner, and much more.

When you create a new team from scratch, it automatically creates an O365 group (and a SharePoint site collection). Whomever you invite to that team is added to the O365 group which is also used to define permissions in other apps and services throughout O365.

But let’s say you were using O365 groups before Teams was cool. You don’t want to create duplicate teams or have to manage twice as many, right? Luckily, you can use existing O365 groups to create new teams.

Create a team using an existing O365 group

In Teams, beneath your list of Teams, click Join or create a team.

Click Create team.

Choose Create from…

Next, click Office 365 group.

If you choose Team, it will copy that Team’s apps, settings, and channels to the new Team (without changing the original Team). This might be useful for classes with similar formats, or creating committees or teams based on a well-received template.

But to create a team from our existing O365 group, we’re going to select Office 365 group.

Now select the existing O365 group for which you’re establishing a new Team, then click Create.

After a moment, your new Team will be created and you’ll be taken to its landing page.

You can verify membership is correct by opening the Team’s menu (ellipses) and selecting Manage team. This

Here you can view owners, members, and guests from the O365 group. You can now modify the O365 group’s membership here if you wish, keeping in mind it affects permissions outside of Teams as well (as is the nature of O365 groups).

Microsoft recommends modifying O365 group permissions via Teams because doing so elsewhere (such as the M365 admin center) will cause a delay in taking effect and removed team members may retain Teams chat access for a couple hours.

May 17, 2019May 17, 2019

Check permissions for an individual or group in SharePoint

If you want to see which groups a user belongs to, or how an individual is granted (or restricted) access to a particular site or resource, use the “Check permissions” button in Site Settings –> Site Permissions (or any advanced permissions page).

SharePoint 2016 example of checking permissions

SharePoint Online example of checking permissions (see specific allowances)

February 26, 2019January 1, 2020

Export SharePoint group membership names and email addresses to Excel

Before we start, if you’re just wanting to email all members of the group you can “select all” then choose “E-Mail Users” from the action menu when viewing the group membership within SharePoint. This opens an Outlook window with all the addresses pre-populated.

But, if you still need an excel sheet of membership for another purpose (perhaps to format a sign-in sheet, generate documents with mail merge, share the list with others, etc.) follow these steps:

With the group open in SharePoint, copy the URL and note the ID number at the end of the URL
Open a new excel workbook
From the “Data” tab, select “New Query” –> “From Other Sources” –> “From OData Feed“
Paste the group URL in the prompt but delete everything after the site address and replace with the following, replacing “6” with your group’s ID from step 1
/_api/Web/SiteGroups/GetByID(6)/Users
When prompted for login credentials you’ll use “Windows” for on-prem/server and “Organizational account” for O365.
Click “Edit” once the group loads so we can choose which columns to keep/delete
Ctrl+click the column headers you want to keep
Right-click a header of a column you’re keeping and select “Remove Other Columns”
Close and Load
You should now see your group membership and email addresses (and any other fields you kept). Save this somewhere and, if updates are made in the future, just click “Refresh all” to bring in new members and remove old.

Updated 8/8/2019: Added step 5 to show the login credentials prompt.

September 4, 2018September 2, 2018

SharePoint workflow troubleshooting: “Item does not exist. It may have been deleted by another user.”

This error message tends to reveal itself whenever you’re dealing with item-level permissions. Try the following to resolve this error.

Note: For any change to a workflow, you’ll need to start/restart your workflow to test it. Resuming a workflow will only resume the previous version of the workflow (still broken).

Continue reading “SharePoint workflow troubleshooting: “Item does not exist. It may have been deleted by another user.””

September 3, 2018September 2, 2018

Securing information by setting item-level permissions in SharePoint without workflow

SharePoint Designer is a fantastic workflow builder – but sometimes, if your workflow isn’t built correctly, implementing item-level permissions via workflow could fail and leave your submitted information or documents vulnerable to data spill. A safer, more reliable method is to use out-of-the-box (OOTB) item-level permissions.

This OOTB method is great because it applies to all items, former and future, while workflows would need to be triggered for previous items to be set. This becomes tricky to do retroactively when your lists could already have thousands of items. This OOTB method is also not dependent on other steps or actions that could fail, as it might be in a workflow.

Continue reading “Securing information by setting item-level permissions in SharePoint without workflow”

September 2, 2018

SharePoint “Cancel Checkout” permissions

When you’re working with item-level permissions in SharePoint, you will see this message in advanced settings:

“Note: Users with the Cancel Checkout permission can read and edit all items.”

Here’s how to check to see if a group or individual has that cancel checkout permission, or add it if needed:

Continue reading “SharePoint “Cancel Checkout” permissions”

Tag: permissions

Create a custom permission level in SharePoint

Create the new, custom permission level

Change permissions on the list

Like this:

Change the email address used for Access Requests on all SharePoint sites and subsites in a web app using PowerShell

Replace the email address used on ALL sites

Replace all instances of a specific user across all sites in the web app

Like this:

Solution: SharePoint site owner with full control unable to approve access requests; site is missing a default members group

Symptoms

Cause

Solution

IF YOU HAVE GROUPS YOU WANT TO SET AS THE DEFAULTS

IF YOU DON’T HAVE GROUPS YOU WANT TO SET AS DEFAULT

Like this:

Read vs Restricted Read vs View Only Permission in SharePoint

Like this:

Creating a Team from an existing O365 group

Create a team using an existing O365 group

Like this:

Check permissions for an individual or group in SharePoint

Like this:

Export SharePoint group membership names and email addresses to Excel

Like this:

SharePoint workflow troubleshooting: “Item does not exist. It may have been deleted by another user.”

Like this:

Securing information by setting item-level permissions in SharePoint without workflow

Like this:

SharePoint “Cancel Checkout” permissions

Like this:

Create the new, custom permission level

Change permissions on the list

Spread the word:

Like this:

Replace the email address used on ALL sites

Replace all instances of a specific user across all sites in the web app

Spread the word:

Like this:

Symptoms

Cause

Solution

IF YOU HAVE GROUPS YOU WANT TO SET AS THE DEFAULTS

IF YOU DON’T HAVE GROUPS YOU WANT TO SET AS DEFAULT

Spread the word:

Like this:

Spread the word:

Like this:

Create a team using an existing O365 group

Spread the word:

Like this:

Spread the word:

Like this:

Spread the word:

Like this:

Spread the word:

Like this:

Spread the word:

Like this:

Spread the word:

Like this: