New command: spo eventreceiver add

[MathijsVerbeeck]

Usage

m365 spo eventreceiver add [options]

Description

Adds an event receiver to the web / list

Options

Option	Description
--webUrl <webUrl>	The URL of the web for which to create the event receiver.
--listTitle [listTitle]	The title of the list for which to create the event receiver, if the event receiver should be registered on a list. Specify either listTitle, listId or listUrl.
--listId [listId]	The id of the list for which to create the event receiver, if the event receiver should be registered on a list. Specify either listTitle, listId or listUrl.
--listUrl [listUrl]	The url of the list for which to create the event receiver, if the event receiver should be registered on a list. Specify either listTitle, listId or listUrl.
-e, --eventType <eventType>	Type of event receiver to create.
-n, --name <name>	Name of the event receiver to create.
-u, --url <url>	Url of the event receiver.
--synchronization [synchronization]	The synchronization state for the event receiver.
--sequenceNumber [sequenceNumber]	Sequence number in which the event receiver will be executed.
--scope [scope]	The scope on which to attach the Event Receiver. Can be either "Site" or "Web". Defaults to "Web". Only applicable when not specifying any of the list properties

Additional Info

Update 31-08-2022, by @martinlingstuyl: Adding Event Receivers using a signed in identity from an AAD app seems to be an issue, as you can read in this thread: https://github.com/pnp/powershell/issues/464 They might be created but not fired. It's possible that you need to sign in using --authType password for this to work.

[martinlingstuyl]

Thanks for the suggestion @MathijsVerbeeck. 🚀 Any https://github.com/orgs/pnp/teams/cli-for-microsoft-365-maintainers with ideas about this?

[Adam-it]

@MathijsVerbeeck thanks for this awesome suggestion 👍 your rock 🤩. Here are my comments/questions/ideas/opinion/(other similar)🤔

1. were you planning on using the /_api/web('webUrl')/eventreceivers) post rest endpoint to achieve this ?
2. also TBH I think we could divide this into two commands (one for web and separate for list) 🤔. So I would suggest we add something like m365 spo web eventreceiver add and m365 spo list eventreceiver add. The command names itself will show at what level (scope) we would like to add the event receiver. Also this would follow our current approach we have in other commands that may be done on different levels (for example roleinheritance break, we have a separate command for list and listtiem)

[MathijsVerbeeck]

@Adam-it Thanks for the feedback.

1. Correct. I was going to use this endpoint (Post for creating).
2. I thought that it would be handier to have it all in one space, and just check what options are filled when the command has been called. Otherwise we would have a lot of duplicate code, with just a seperate URL being called (_api/web()/eventreceivers and _api/web('webUrl')/lists('listTitle')/eventreceivers).

[martinlingstuyl]

Hi @MathijsVerbeeck, I think we should clarify the list options a bit more. Just did that and updated the --r to --u and updated the --scope option a bit.

Could you update the other issues to align with my clarifications of the scope and list options?

[MathijsVerbeeck]

@martinlingstuyl Now I see that we have a duplicate option -u (webUrl and url). Is this supposed to be like this?

[martinlingstuyl]

Hi @MathijsVerbeeck, good catch! Typically, the short option refers to the command noun. In this case we should apply the shorts to the eventreceiver object that we are creating. So use the -u for the event receiver url and not for the webUrl option.

[MathijsVerbeeck]

@martinlingstuyl I've updated the Options for every issue. Could you have a look?

[waldekmastykarz]

If we look at other commands, like spo contenttype add or spo field list, we don't have a separate namespace for web and list. Instead, we have a single command with options that allow you to work on the scope of web or list. Current spec is consistent with what we have so I'd suggest we don't split it into separate commands.

[martinlingstuyl]

Ok, so apparently no other points arise, let's open it up!

[martinlingstuyl]

I've added a note in the specs about Event Receivers being added but not fired. I've recently run into that with the PnP PowerShell commandlets. It can be worked around by using the older UseWebLogin parameter. It seems it has something to do with the AD App that's used when signing in interactively and Event Receivers, expecting the App ID to refer to the older SharePoint Service Principals.

[Adam-it]

I've added a note in the specs about Event Receivers being added but not fired. I've recently run into that with the PnP PowerShell commandlets. It can be worked around by using the older UseWebLogin parameter. It seems it has something to do with the AD App that's used when signing in interactively and Event Receivers, expecting the App ID to refer to the older SharePoint Service Principals.

Nice research 👍. Thanks for being aware of all 🤩

[martinlingstuyl]

I think this needs some research. It might be impossible implementing this with azure AD auth. @waldekmastykarz, you tried setting up cookie auth a short time ago. I fear we might even need such a thing if we want to successfully create event receivers that are actually fired. See the note up top about issues surrounding this in PnP PowerShell.

[waldekmastykarz]

My scenario for cookie-based auth was a bit different. The problem with getting a cookie from a terminal is that you need a browser window and you need to do it cross-platform which means bringing in electron which gets complicated pretty quickly and might not be worth the effort.

[milanholemans]

Because it seems to be impossible to create a working event receiver with our current way of doing auth, shall we close this issue?

[martinlingstuyl]

Good point, we could only implement this if we supported classic sp add-in client id and secret. And we don't.... Let's close for now