New command: Start a meeting in a team

[macthedev]

Usage

meeting-new -t [team] -m [time]

Description

My use case is this:
To be able to schedule a meeting in a team at the beginning of the day. This will enable the meeting to act as a 'virtual office' which your team can jump in and out of (gamers, think of a voice channel in a Discord server). This will allow you or anyone in the team to be able to sit in the 'virtual office' passively and others can jump in freely.
It would be useful to create a notification at the start time so that people can easily join the 'virtual office' when they log in.

I'm not sure how fitting this would be with how the CLI works but I think it is a great idea so would love to hear what you guys think of the idea!

Options

Option	Description
-o, --option <option>	option
-t --team [team]	The team in which to start the meeting
`m --time [time]	The datetime when to start the meeting

Additional Information

This has been raised on the Teams user voice here:
https://microsoftteams.uservoice.com/forums/555103-public/suggestions/34617772-option-for-passive-voice-channels

[waldekmastykarz]

@mac-windle interesting suggestion! Do you know if there is an API for it?

Regarding the command design, I'd say that the team is required. Would we also need the channel in which the meeting should be started. We could keep the time optional and if not specified we'd start the meeting right now. What do you think?

[macthedev]

I know the Graph API can be used but I have not yet used it in practise for Teams meetings or calls.
https://docs.microsoft.com/en-us/graph/api/resources/teams-api-overview?view=graph-rest-1.0

I absolutely agree with your comments about the required and optional parameters.
Good call with the meeting start time

[waldekmastykarz]

Hey @mac-windle, are you still working on this? Do you need any assistance?

[macthedev]

Hi.
I have not done any work on this feature.
I think I may have possibly misunderstood the intention of posting the idea here as I meant it purely as a suggestion, not to work on myself - oops!!

[waldekmastykarz]

Ah, that's my bad. I wrongfully assumed you were working on it. Sorry 😊
It's perfectly fine to suggest new features but not implementing them yourself. You did the right thing 👍

[jhagstrom]

This looks like fun, the onlineMeetings endpoint seems promising. From what I gather a start datetime, enddatetime and organizer are the smallest set of required params. Hooking it to a specific channel seems doable through the chatInfo property, chatMessage is in preview though.

But regarding the use case, this seems like a casual user operation but an admin user will need to grant you as a casual user permissions to the PnP AAD app right? I really like the idea of being able to use CLI commands for personal (i.e. non-admin) use though.

[waldekmastykarz]

@jhagstrom some commands in the CLI are admin-focused and such justify the requirement for an admin consent. On the other hand, like you mentioned, that's not the case for all commands. So if there are commands that require permission scopes that don't depend on admin consent, you could create a custom AAD app with just these permissions and use it instead the one we use by default. Does this make sense?

[jhagstrom]

I tried the /beta/me/onlineMeetings/createOrGet endpoint and it works. There are some chained requests required to put together the body to post though :

• Tenant id, that's the tid claim in the access token, or how is that usually retrieved?
• User id and upn from calling user to use as organizer, from /me/ or also from access token maybe
• Thread, (i.e. channel) id, I guess /me/joinedTeams with OData filter on name to get the id which can then be used in /teams/{id}/channels also filtered on channel name

I had to grant myself OnlineMeetings.ReadWrite, not sure if the default AAD app has that granted, how do I see that by the way?

[jhagstrom]

Good news. I tried some more and it works without having tenant id or upn of organizer in the body.
Just need to remember to provide a fresh guid to put as externalId every time, otherwise you perform the 'get' part of createOrGet

[waldekmastykarz]

Nice! Regarding the necessary permissions, when we add new commands that require additional permissions, we extend the AAD app with them. The exception so far has been Yammer which isn't available in all tenants and which we can't include by default. For that we're using dynamic consent.

So, do you want to pick this up given you've done all the research? 😄

[jhagstrom]

Yes, I can give it a try.

[garrytrinder]

Hey @jhagstrom 👋🏻 How are you getting on with this command?

[jhagstrom]

Not at all I am afraid. I have not had the time for a while now.

[waldekmastykarz]

Understood and it's fine. Do you want to keep it or let others help?

[Abderahman88]

I would suggest to split the participants in 2 properties : attendees and organizer
This makes it easier to check you only have 1 organizer and 1 or more attendees. It's also in line with the standard docs.

As for the organizer, this could be a normal user or a team.

m365 teams meeting create --organizer [email protected] ...
m365 teams meeting create --organizer [email protected] ...

[waldekmastykarz]

Good call. What do you think about defaulting the organizer to the current user if none specified?

[Abderahman88]

Great idea. In most cases, the organizer will be the current user.

Issue 1) At the moment I'm not able to change the organizer to a different user or team.
Based on the docs, an application access policy has to be configured to make it work.

I'll try it out and check if it works.

Issue 2) the Teams desktop app can make a distinction between required and optional participants. I don't think the REST API has these capabilities.

[waldekmastykarz]

Good finds. Thanks for sharing. If it's not possible to use a different organizer through the API, then let's drop the option and automatically assign the current user. If it's possible with additional configuration, let's include it in the command's docs so that everyone knows what's needed for it to work.

[mkm17]

Hello everyone, I'd like to take a look at this task. I've done some quick research based on previous comments, and I believe I understand what needs to be done. My only current concern is regarding the MS Graph API permissions. I'll try to handle it on my own initially, and if I have any questions, I'll reach out on the CLI Discord channel :) Please let me know if it's okay to assign me to this task.

[martinlingstuyl]

Hi @mkm17, that's superb! I'll assign you immediately... the permission can be added to the PnP management shell Azure ad app when the PR is merged. For your development work, you should create your own app reg (with the required permission) and use it to sign in. You may find the instructions for that on our site.

💪 happy coding!

[martinlingstuyl]

The specs are not quite clear yet though. Relevant comments from here downward I believe.

Could you get back to us during your initial steps into this space so that we can finalize specs based on your research?

[mkm17]

@martinlingstuyl OK, I should have more information by the end of next week.

[mkm17]

Hi @martinlingstuyl, From what I can see in MS Graph, we can use create endpoint option instead of createOrGet.

With the first endpoint, we have the ability to add all the properties that are not marked as read-only, as outlined in this link. What's interesting is that none of these properties are mandatory, meaning we can create a meeting without specifying a subject or start date. In such cases, the new meeting will start immediately and automatically end after one hour.

A list of properties that can be configured for a new meeting includes:

{
  "allowAttendeeToEnableCamera": "Boolean",
  "allowAttendeeToEnableMic": "Boolean",
  "allowedPresenters": "String",
  "allowMeetingChat": {"@odata.type": "microsoft.graph.meetingChatMode"},
  "allowParticipantsToChangeName":"Boolean",
  "allowTeamworkReactions": "Boolean",
  "broadcastSettings": {"@odata.type": "microsoft.graph.broadcastSettings"},
  "chatInfo": {"@odata.type": "microsoft.graph.chatInfo"},
  "endDateTime": "String (timestamp)",
  "isBroadcast": "Boolean",
  "isEntryExitAnnounced": "Boolean",
  "joinMeetingIdSettings": {"@odata.type": "microsoft.graph.joinMeetingIdSettings"},
  "lobbyBypassSettings": {"@odata.type": "microsoft.graph.lobbyBypassSettings"},
  "participants": {"@odata.type": "microsoft.graph.meetingParticipants"},
  "recordAutomatically": "Boolean",
  "shareMeetingChatHistoryDefault": { "@odata.type": "microsoft.graph.meetingChatHistoryDefaultMode" },
  "startDateTime": "String (timestamp)",
  "subject": "String",
  "watermarkProtection":{  "@odata.type": "microsoft.graph.watermarkProtectionValues"}
}

Since everything appears to be quite useful, I would prefer to keep the initial version simple, focusing only on essential options such as start and end date-time, subject, and participants. For the original concept discussed in this thread, which relates to a Discord voice channel meeting, these elements should suffice.
In the intended solution, someone should handle the joinWebUrl. If it is unavailable or the end date has passed, then it becomes necessary to create a new meeting and update a joinWebUrl.

When it comes to creating a meeting under a specific user, I can use something that is created in the meeting attendance report command. It involves checking if an isAppOnlyAccessToken is being utilized, and in such cases, the endpoint switches to /users/{id} instead of /me.

In summary, for the initial version, I would recommend creating the command with the following options:

m365 teams meeting create   (To establish a meeting right away that lasts for one hour.)
m365 teams meeting create --startDateTime "date" --endDateTime "date" --participants ["[email protected]", "[email protected]"]  (having in mind that all options are optional)
m365 teams meeting create  --organizerId "organizerId"  (in a case when App Only Access is used)

Let me know what you think. Should we include more options in the command? Perhaps we can categorize certain boolean properties and place them under a single --aditionalOptions argument.

[martinlingstuyl]

Hi @mkm17, great work researching this! i agree with you it's best to use the create endpoint for this. The amount of properties that we can use seem nice. Let's keep it basic for now indeed, we can always add extra options later indeed.

Let's draft a table to spec out the options in more detail:

Option	Description
-s, --startTime [startTime]	The start time of the meeting. If not specified, the startTime will be set to the current time.
-e, --endTime [endTime]	The start time of the meeting. If not specified, the endTime will be set to one hour after the startTime.
--subject [subject]	The subject of the meeting.
-p, --participantUserNames [participantUserNames]	A comma-separated list of participant UserNames.
-o, --organizerEmail [organizerEmail]	The email of the organizer of the meeting. If not specified, defaults to the current user.
-r, --recordAutomatically	When using this flag, the meeting will be recorded automatically.

Remarks

I thought I'd add recordAutomatically as a flag, as that seems super useful.

DateTime values may be specified as ISO-8601 formatted.

There are some more interesting flags we could add, but let's keep it simple for now.

[mkm17]

Hi @martinlingstuyl, I have created a new PR #5550 that includes an added command. I made some changes to the initial concept, such as using participants' UPNs instead of emails. I believe it would be easier to discuss further changes on the existing code. :)

[martinlingstuyl]

That's great @mkm17! I understand you used upns. In a next version we could include additional properties like participantIds and participantEmails, we do that in other places as well. But upns is a fine place to start.