Is your feature request related to a problem? Please describe.
Via API, admin cannot disable “record active speaker, gallery view and shared screen separately” but does allow disabling of “Speakerview” and “galleryview” individually. Without being able to disable “record active speaker, gallery view and shared screen separately” both galleryview and speakerview are (essentially) still enabled. This is flawed to act as if you are disabling speakerview or galleryview via API but ultimately, a 3rd setting still enables it. There needs to be an API solution to disable “record active speaker, gallery view and shared screen separately” or else speakerview and galleryview are never disabled. This was discussed and experimented with in this thread here.
Describe the solution you’d like
An API setting to disable “record active speaker, gallery view and shared screen separately” similar to the existing API for “speakerview” and “galleryview”.
Describe alternatives you’ve considered
The alternative is an admin using a web browser to change tens of thousands of their users’ settings individually, one at a time.
Thank you for submitting this feature request! I’ve since passed this information along to our engineering team. I’ll be sure to keep you updated. (ZOOM-242390)
Hi @MaxM : I was talking with our CSM and Zoom Account Executive yesterday and I was telling them that this API feature request would not be needed for all end-users (my org in particular) if Zoom (dev or support) was able to implement this change. The change was to unselect the “3rd” recording choice for the entire site. We would need to arrange a time that is acceptable for Zoom and Mason (us), likely outside of the Spring semester. Both our deputy CIO and our executive director agree with my manager and me that this looks to be a fix/break issue that is part of a flawed implementation of API → Why allow someone to True/False two attributes that are overridden by a third unchangeable attribute?
Not being able to disable this 3rd and final selection sitewide is obtrusive to administrators that need to weigh costs to the organization with recording storage availability. Is Zoom going to either fix this for the API or for our organization (gmu.zoom.us)? @MaxM
Bump. We are paying for additional TB of storage from Zoom, partially because of us being unable to disable the recording feature sitewide (without locking). Hoping a dev or Zoom admin can just make the (scheduled) change to our site for us, offer us an API solution, or at minimum acknowledge this might be a bug.