Add SiteCollection as scope to EventReceivers cmdlets

[bhishma]

Is your feature request related to a problem? Please describe.
*-PnPEventReceiver cmdlets currently only support List or Web scopes. It would be wonderful to have Site as another scope to get site collection level event receivers.

Describe the solution you'd like
Get-PnPEventReceiver -Scope Site or something like that.

Describe alternatives you've considered
I currently use CSOM to work with site collection level event receivers.

$clientContext = Get-PnPContext
$site = $clientContext.Site; 
$clientContext.Load($site)
$eventReceivers = $site.EventReceivers
$clientContext.Load($eventReceivers)
Invoke-PNPQuery

Additional context
Add any other context or screenshots about the feature request here.

[bhishma]

@erwinvanhunen , this actually seems to be an issue -- not necessarily with PnP but the way the authenticated context is created.
There is some difference between context created by SharePointPnPPowerShellOnline module and new PnP.PowerShell module.

I'm executing following commands to register an event receiver at the site collection level. (The event receiver blocks creation of Lists of certain templates). In both cases, I see event receiver is registered. However, it does not work (does not prevent the list creation) when registered using PnP.PowerShell but works when using old module.

I delete event receiver before connecting and registering with other module. So I know both modules are able to register.
I use different PowerShell sessions to switch between modules.

Another interesting observation is that I cannot delete the event receiver from site collection that is registered using other module. I get 401:unauthorized.
I'm using same account, same event receiver endpoint.

Connect-PnPOnline -Url "https://domain.sharepoint.com/sites/newsite" -Credentials "myaccount" #stored cred
$newSiteContext =Get-PnPContext
$site = $newSiteContext.Site
$newSiteContext.Load($site)
$newSiteContext.ExecuteQuery()
$listAddingRER = New-Object Microsoft.SharePoint.Client.EventReceiverDefinitionCreationInformation
$listAddingRER.EventType = "ListAdding"
$listAddingRER.ReceiverName = $listRERName
$listAddingRER.ReceiverUrl = $listRERUrl
$listAddingRER.Synchronization = "Synchronous"
$listAddingRER.SequenceNumber = 10001    
$eventReceivers = $site.EventReceivers
$newSiteContext.Load($eventReceivers)
$newSiteContext.ExecuteQuery()
$eventReceivers.Add($listAddingRER)
$newSiteContext.ExecuteQuery()

It also works if I go about CSOM way to create context.

$newSiteContext = New-Object Microsoft.SharePoint.Client.ClientContext("https://domain.sharepoint.com/sites/newsite")
$credentials = New-Object Microsoft.SharePoint.Client.SharePointOnlineCredentials($UserName, $secureString)                            
$newSiteContext.Credentials = $credentials 

Additionally, I tried registering using a Console application. There seems to be similar experience. If I create a context using SharePointOnlineCredentials, it works. If I create context using AccessToken (with AllSites.FullControl scope and with a account that has Tenant Admin access), it does not work (RER is registered but does not work).

Do you suggest I open a support case with Microsoft or is it something it can be investigated here?

[erwinvanhunen]

We unfortunately cannot fallback to SharePointOnlineCredentials anymore as those do not exist anymore in the later CSOM builds for .NET Core. E.g. we have to use OAuth2 based authentication using access tokens. As such there should be no difference. As the access is delegated access, all the actions performed on the server are performed under your identity. Indeed, if this fails for you, we can't fix that as we do not have control over the server code.

What you could try is programmatically make a request to the server with your own access token added to the request. It's a bit of a setup, I understand that, but if that fails we can make sure it's not PnP code doing it. Also when you communicate with MS, if you mentioned the word PnP, there is a huge risk they will redirect you back here... which is not helping you that much. That's why it's important to understand if it's our implementation of handling the access code (we however fully support MS guidelines there and it has been working like this for quite a while already) or it it's something server side.

[bhishma]

Thank you for responding. Yes, I completely agree it is NOT PnP doing. I'm just pointing out that the legacy way works but in this specific scenario, oath2 token based authentication seens to be not working as expected.

I have proved it out outside of PnP usage. (I have learned my lesson to not mention PnP in MS tickets :) )
MS is investigating.

Wondering if anyone in the community can reproduce the behavior I'm seeing..
I'll come back and update this thread when I get resolution.

Again thank you and the community for all you do.

[bhishma]

I tried to register EventReceivers using RestApi. Old module vs new module resulted in the same behavior that I'm experiencing as above. When I execute following command with old module, EventReceiver works (event receiver registered and triggered), however with new module, EventReceiver doesn't work (registered but not triggered).

$body=@'
{
    "ReceiverName": $rerName,
    "SequenceNumber": 10001,
    "Synchronization": 1,
    "EventType": 104,
    "ReceiverUrl": $rerUrl
    }
'@

Connect-PnPOnline -Url $siteUrl -Credentials "myaccount"
$result=Invoke-PnPSPRestMethod -Method Post -Url '/_api/site/eventreceivers' -ContentType 'application/json; charset=utf-8' -Content $body

I found this StackOverflow thread that matches what I am seeing. Hope this gives some more detail/context.

[github-actions]

This issue is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 5 days

[bhishma]

The issue I'm seeing seems to be a result of how we implemented RERs.
I believe this enhancement would be completed and helpful for community, if the two PRs are merged.
Please let me know if those need some more work.
if you think this enhancement is not necessary., We can close this issue.