isSupportLocalRecording always returning SUCCESS

[KieranAC (Kieran)]

Description
I believe the isSupportLocalRecording, which determines if a particular user can record, always returns success.

From docs:

If the specified user is enabled to start local recording, the return value is ZoomSDKError_Success. Otherwise failed.
- (ZoomSDKError)isSupportLocalRecording:( **unsigned** **int** )userid;

Which macOS Meeting SDK version?
5.9.3

To Reproduce(If applicable)

Initial Setup:
Client A - custom app with SDK. User is not host but can reclaim it.
Client B - Zoom client. User is not host. This client is attempting to record.
Client C - Zoom client. User is host.

From Client C:

Right click user B. I can see that there is an option to allow local recording. This means that User B does not have permission to record.

If we reclaim host on Client A and call the API, the following method returns SUCCESS

[[[[ZoomSDK sharedSDK] getMeetingService] getRecordController] isSupportLocalRecording:self.userID];

I believe this is incorrect

If Client B attempts to record at this point (from zoom client) they get an error:

This seems consistent with the dropdown menu in Client C. But the SDK client thinks this user is able to record.

If Client C reclaims host, and then allows recording, then it updates in the Zoom client accurately:

Client B can now record successfully.

If Client A reclaims host again (the custom SDK app), and calls canSelfRecordLocalFiles method again, it returns YES like before. This time that is correct, but it seems to always return YES.

If Client A removes permission from Client B to record using

allowLocalRecording:NO User:self.userID

Then Client B can no longer record.

But at this point, the isSupportLocalRecording method is still returning SUCCESS.

Device (please complete the following information):

• Device: Apple MacBook Pro (13-inch, M1)
• OS: 12.0.1

[jon.zoom (Jon)]

Hi @KieranAC,

I think that you may be looking for the canStartRecording method, rather than isSupportLocalRecording. Does this have the behavior you are expecting? The isSupportLocalRecording method is checking if the meeting that the current user is in supports it.

Our documentation on that method could definitely use some work, as this is not the least bit obvious based on the description we have there at the moment. I’ll work with the team on getting that updated and see if we can fit it into the release this month.

Thanks!

[KieranAC (Kieran)]

That might be it. Ill give it a try.

[KieranAC (Kieran)]

@jon.zoom

I don’t think that’s it. The ** canStartRecording:(BOOL)isCloud;** method returns YES if the current user is enabled to start recording.

I want to know if a different user can start recording. Meaning a method that you would pass a userID to.

The *canAllowDisallowRecording method seems to work, and returns if the current user (the host) can allow/disallow other users from recording. This is returning YES in my use case.

The canStartRecording BOOL )isCloud method seems to return YES if the current user can start recording. Since I’m the host, this always returns YES. This method seems to work as I use it elsewhere in my code. It returns NO if I’m not the host and haven’t been granted recording access.

The ** allowLocalRecording:( BOOL )allow User:( unsigned int )userid** grants recording ability to a particular user. This seems to work since I can remove/allow permissions to a Zoom client user, and the Zoom APP UI reflects the change.

To determine if another user can record, I expect the ** isSupportLocalRecording:( unsigned int)userid** to be the correct method, since that is the only one that takes a userID as a parameter. From the docs: “Determine if the user owns the authority to enable the local recording.”

Unfortunately this is always returning SUCCESS. I just sanity tested again and it returns SUCCESS for a Zoom client user. In that case you would expect that user to be able to record, but recording doesn’t work for that user in the zoom client.

[jon.zoom (Jon)]

Hi @KieranAC,

Thanks for the additional context around your use case. I can reproduce the behavior you are seeing. There is a change coming in the next version of the SDK this month which will introduce a new method of obtaining recording permission, so this behavior may be related to that change. If this issue is still reproducible in the next version, we’ll need to investigate further.

Thanks!

[KieranAC (Kieran)]

thanks, look forward to that release

[KieranAC (Kieran)]

@jon.zoom I tried the same steps above with the new SDK version and still see the same issue.

SDK v5.9.6

[jon.zoom (Jon)]

Hi @KieranAC,

Thanks for confirming. We’ll investigate and let you know once we have any updates.

Thanks!