Collaborative Meeting Notes can be used in a Teams meeting. Teams creates a Loop component in the creator’s OneDrive. The creator is the person who first clicks on the note. It does not have to be the organizer.
As an example, for simulation purposes in the old Teams calendar.
The Loop component is shared with the permission “Can edit” to all invited participants. If you later add additional participants to the meeting, the component is not automatically shared with the new participants.
Microsoft notes in the documentation about Loop components:
Because Loop components are designed for collaboration, the components are always shared as editable by others, even if your organization is set to create shareable links that have view-only permissions as the default value for other file types.
The note refers to the global sharing configuration in the SharePoint Admin Center.
Now, if you create a Collaborative Meeting Note with the new Teams calendar (in a new meeting), the component can be shared as view-only. This is a frustrating (and often incomprehensible) situation for organizers and participants.
This only affects Collaborative Meeting Notes in the new Teams calendar. Other Loop components are not affected.
It seems the new Teams calendar uses the default sharing configuration from the SharePoint tenant for Collaborative Meeting Notes, at least in some scenarios.
It is not consistent. My tests over the last few days have shown different results.
- Last Wednesday, permissions in the new Teams calendar were set to “Can view”
- Last Friday, permissions in the new Teams calendar were set to “Can edit”
- Today (Monday), permissions in the new Teams calendar are again set to “Can view”
Microsoft may has a random technical issue between the new Teams calendar and the notes.
A PowerShell configuration can help.
A SharePoint administrator can define default sharing permissions for Loop components, separately for OneDrive and SharePoint.
The configuration uses two properties in the SharePoint tenant: CoreLoopDefaultSharingLinkRole and OneDriveLoopDefaultSharingLinkRole
Get-SPOTenant | select CoreLoopDefaultSharingLinkRole,OneDriveLoopDefaultSharingLinkRole,CoreLoopDefaultSharingLinkScope,OneDriveLoopDefaultSharingLinkScope | fl
Both properties are defined with “None” as the default value, which means Loop uses the global sharing configuration.
Collaborative Meeting Notes are stored in OneDrive, so my situation can be narrowed down to the OneDriveLoopDefaultSharingLinkRole property.
Note:
The new Teams calendar is not yet available for channel meetings. Collaborative Meeting Notes are always shared correctly when using the old calendar. The CoreLoopDefaultSharingLinkRole property (for SharePoint sites) should not be necessary in this case.
OneDriveLoopDefaultSharingLinkRole
This parameter sets the default share link role for Loop and Whiteboard files on OneDrive sites.The valid values are:
- Edit
- View
- None (Default value)
- Review
- RestrictedView
For my test, I am changing the configuration for a single OneDrive.
$OneDriveSite = Get-SPOSite <OneDriveUrl>
$OneDriveSite | select LoopDefaultSharingLinkScope,LoopDefaultSharingLinkRole | fl
Set-SPOSite -Identity $OneDriveSite -LoopDefaultSharingLinkRole Edit
Get-SPOSite -Identity $OneDriveSite | select LoopDefaultSharingLinkScope,LoopDefaultSharingLinkRole | fl
I am planning a new meeting and creating the Collaborative Meeting Note.
A check confirms the sharing permission ‘Can edit’. The sharing configuration from OneDrive is used.
My test was for a single OneDrive.
If I run the same test with a different account, Teams shares the component with ‘Can view’ again. For the second test, OneDrive uses the global sharing configuration from the SharePoint tenant.
