StartTime property missing on RecurringMeeting

[pbros]

The StartTime property that is part of the ScheduledMeeting class is missing from the RecurringMeeting class.

The value is returned by the Zoom Api, so it should be mapped to the RecurringMeeting objects.

Example JSON returned from Zoom Api (notice Type = 8)

{
    "uuid": "***",
    "id": 11111111,
    "host_id": "***",
    "topic": "Meeting Name",
    "type": 8,
    "start_time": "2022-12-02T19:00:00Z",
    "duration": 120,
    "timezone": "America/New_York",
    "agenda": "Agenda",
    "created_at": "2021-12-24T16:29:53Z",
    "join_url": "https://us02web.zoom.us/j/*****?pwd=****"
}

[Jericho]

Recurring meetings that I'm familiar with do not have a start time like scheduled meetings do but rather they have multiple occurrences and each occurrence has it's own start time. For example, in the following screenshot you can see that the Occurrences property of my recurring meeting is an array containing multiple MeetingOccurance, each one having a different start time (the screenshot shows the first occurrence):

However, as you pointed out, your sample JSON contains Type = 8 which corresponds to a "recurring meeting with fixed time". Evidently, there is a subtle nuance between recurring meeting without fixed time (this is the type of recurring meeting I'm familiar with) as compared with those that do have a fixed time (which is what your sample JSON contains) and I must admit that I am not familiar with it.

I will need to take some time to familiarize myself with recurring meeting with fixed time to understand their data model. Maybe there are other differences in addition to the one you are pointing out.

[pbros]

Note that start_time and time_zone are part of the schema returned from the List Meetings api. I would suggest that all properties present in this call be added to the Meeting base class.

https://marketplace.zoom.us/docs/api-reference/zoom-api/methods#operation/meetings

For your information, I am trying to use this api to display a list of the meetings, ordered by start_time. I understand that the Occurences provide more information about all of the times for the meeting, but it requires an additional API call to fetch that information.

[Jericho]

I would suggest that all properties present in this call be added to the Meeting base class.

I put a a lot of thought when I designed the data model for the various meeting types. Some properties where added to the meeting class when appropriate, some properties where added to the scheduled meeting class, some to the recurring meeting class and some to the instant meeting class. Not all properties are relevant for all types of meetings therefore it doesn't necessarily make sense to add all these properties to the abstract base class.

Having said that, keep in mind that Zoom regularly adds new attributes to the JSON returned by their API which means that it's entirely possible that they enhanced the data and that ZoomNet has not kept up with the improvements.

I understand that the Occurences provide more information about all of the times for the meeting, but it requires an additional API call to fetch that information.

You do not need to make additional API calls to fetch more detailed information about each meeting, you simply need to cast each one to their concrete class (as opposed to the abstract base class). See this discussion where I show a C# code sample to accomplish this.

[Jericho]

Can you share with me how you create your recurring meeting? The reason I ask is that I seem to be unable to recreate your scenario.

I create my meeting with the following JSON (notice type=8 and also notice the presence of the start_time):

When I subsequently retrieve the meeting, I get the following JSON (notice type is still 8 and notice the start_time is NOT at the root level but rather under the occurences):

[pbros]

The meeting was created by the web interface. I don't think anything "special" was done to create it, but when I go to edit it, this is what I see

Also, when the RecurringMeeting object is created by the Meetings.GetAllAsync call, the occurences are not populated

The occurences are also not present in the json returned from /v2/users/******/meetings?type=scheduled&page_size=30

[Jericho]

This is really strange: a recurring meeting with zero occurrences!?!?!?! I have never seen this. Let me try to recreate by creating a new meeting in the web interface...

[pbros]

Note that If I get the meeting details using client.Meetings.GetAsync(meeting.Id) and not client.Meetings.GetAllAsync(..), then the occurrences are there in the JSON, but the start_time is not present (only available on the occurrences)

[Jericho]

I'm starting to think that GetAllAsync returns a "summary" of each meeting as opposed to all the available info. If that's the case, it means this API behavior changed at some point.

[Jericho]

I also realize that I wasn't reproducing the problem because my test was using Meeting.GetAsync rather than GetAllAsync.

I switched to GetAll, and I indeed see the same behavior that you are reporting:

[Jericho]

I notice the exact same situation when retrieving webinars: the API returns a "summary" of each webinar but ZoomNet assumes that all the info if present and returns an array of Webinar objects that can be cast into their concrete type (i.e.: RecurringWebinar or ScheduledWebinar).

I am really perplexed by this situation. Either I designed Meetings.GetAllAsync and Webinars.GetAllAsync incorrectly in March 2019 or they worked perfectly fine for some time and Zoom changed the behavior of their API at some point.

It's entirely possible that I made a mistake but I find it hard to believe that I made such a big error and nobody (including myself!) noticed the problem in the intervening 3 years. On the other hand, I also find it hard to believe that Zoom would make such a major change to their API and wouldn't mention it in their release notes (I spent the last few hours searching and reviewing their release notes and didn't find any indication of such a change).

Either way, I need to resolve this problem.

[pbros]

One of my objectives with using the library is to create an internal dashboard where users will be able to see all the meetings scheduled with our different sub-accounts. Essentially, I'd like to develop something similar to the Zoom Web Interface where you see the list of meetings, but for all of our sub-accounts.

If I have to call GetAsync() for each meeting to get the start times of the different occurrences, I think I will hit the rate limit pretty quickly.

Looking at the documentation, there might another call I could use, but it doesn't seem to be implemented yet in ZoomNet.

https://marketplace.zoom.us/docs/api-reference/zoom-api/methods/#operation/reportUpcomingEvents

Could you look into adding it?

(Edit: Trying out the API with Postman seems to only return Past Meetings...not super useful in my case)

[Jericho]

Regarding your feature request: please raise an issue so we can track it separately.

Regarding the problem at hand, I intend to make the following changes to the GetAllAsync method on the Meetings resource:

• The description will clearly state that the result is a "summary" of each meeting
• Add a remark to indicate that developers must invoke GetAsync in order to retrieve a given meeting's full details
• The method will return an array of MeetingSummary which is a new model class that will be created. This new model will have a dozen or so properties (such as Agenda, Type, Uuid, TimeZone, StartTime, StartUrl, etc.). I hope the name of this model makes it clear that it contains only some properties for a given meeting. This is a breaking change

The result will be something like this:

P.S.: the same changes will be applied to the GetAllAsync method on the Webinars resource.

[pbros]

Looks great!

[Jericho]

I just published a beta to my MyGet feed (See here). Take it for a spin and let me know if it works as you expect. If so, I'll be able to release tomorrow.

[pbros]

I just tested it and it works great. It does exactly what I need when using the Upcoming meeting type. Thanks!

[Jericho]

Excellent, thanks for confirming.

[Jericho]

🎉 This issue has been resolved in version 0.44.0 🎉

The release is available on:

• GitHub Release
• NuGet Package

Your GitReleaseManager bot 📦🚀