Allow Administrators to schedule meetings for all users

[mikhail-ict]

There is an Owner account with a Business / Enterprise or Education license on Zoom. That Owner manages users, licenses and meetings for these users.

As a Moodle admin, it is possible to "Log in as" other users and create meetings that way. Would it be possible, for admins and managers on Moodle, to simply select a lecturer from a list during meeting creation or even tie that selection to the assigned Lecturer role (or similar) of a module? There can be a dropdown list for selecting both a Host or Alternative Host that is sourced from the assigned Lecturers (or similar roles) that match Zoom e-mail addresses.

I can see mod_zoom is utilising schedule_for feature provided by Zoom. I tried setting up the permissions on Zoom to be able to schedule for other users, but the fields are still not visible on Moodle... Can someone advise on how to avail of the schedule for feature?

Thank you.

[mhughes2k]

The only other necessity is that both you and the person you're scheduling for have to also hold the capability to create Zoom activity instances in the class (this might be a bit weird for admins as they don't technically hold any capabilities unless explicitly added)

Practically speaking there isn't a way to allow an admin to schedule any user because the admin has to have been given that right to the user in Zoom, and in doing so the "admin" gets the ability to see all of the user's meetings in Zoom.

Making Moodle automatically grant that right for admins for all users (which you can use the API to script) felt like quite an over stepping of responsibilities and prejudiced individual institutions' own decision making about that level of automatic delegation of rights in Zoom.

[mhughes2k]

We use {{get_enrolled_users()}} so I'm pretty sure you need to have an enrolment record in the course for this to return you.

[jrchamp]

@mhughes2k I think what @mikhail-cct is saying is that Moodle administrators can already "Log in as" any user and thereby create Zoom meetings for that user.

It seems reasonable to me if this request is to allow a Moodle administrator to create a Zoom meeting for another user (directly, not via schedule_for) as long as that user has the addinstance capability in the context. Overall, it seems like a quality of life improvement instead of a dire need given that there is a workaround (albeit an annoying workaround). It sounds like it will be complicated to make it work without breaking the schedule_for behavior, so overlaying it on top of schedule_for using some kind of flag/distinguisher might avoid the need to duplicate a lot of the work that has already been done to support that functionality.

[mikhail-ict]

We use {{get_enrolled_users()}} so I'm pretty sure you need to have an enrolment record in the course for this to return you.

Perfect! This is exactly what I was looking for – the admin needs to be enrolled into the course. It works now and I can see the fields.

@mhughes2k I think what @mikhail-cct is saying is that Moodle administrators can already "Log in as" any user and thereby create Zoom meetings for that user.

It seems reasonable to me if this request is to allow a Moodle administrator to create a Zoom meeting for another user (directly, not via schedule_for) as long as that user has the addinstance capability in the context. Overall, it seems like a quality of life improvement instead of a dire need given that there is a workaround (albeit an annoying workaround). It sounds like it will be complicated to make it work without breaking the schedule_for behavior, so overlaying it on top of schedule_for using some kind of flag/distinguisher might avoid the need to duplicate a lot of the work that has already been done to support that functionality.

I understand what you are saying, yes. In the light of the above solution to my problem – would it be possible to adjust the behaviour, so that at least the Admin/Manager doesn't need to be enrolled into each course for the schedule_for to be visible? Also, would it be possible to have a drop down menu (similar to the one used for "Schedule meeting for") for Alternative Hosts, as well as the text field, that is already there, listing the same choices used for "Schedule meeting for"?

The reason why I bring this up – in many colleges, especially doing non-IT subjects, school managers have to be creating numerous Zoom Meetings (sometimes even 100+) for lecturers and tutors. This is where this functionality becomes critical: the ability to schedule meetings for others without extra hacks on the Moodle side.

Thank you so much for getting back to me @mhughes2k @jrchamp

[jrchamp]

Here's the current code: https://github.com/ucla/moodle-mod_zoom/blob/1468c4268ccc6d5abfb61e992f3646be915726aa/mod_form.php#L87-L88 Instead of checking enrollment via get_enrolled_users(), we could check capability using something like get_users_by_capability(). However, you still wouldn't want to have the meeting host always be the admin/manager because of the simultaneous meeting limitation, but it may be helpful in some contexts.

[mikhail-ict]

However, you still wouldn't want to have the meeting host always be the admin/manager because of the simultaneous meeting limitation, but it may be helpful in some contexts.

The host would always be the primary lecturer of the module and not the admin/manager and Alternative Host would be a second lecturer or tutor. The admin's job in this case is simply to create a meeting for someone else to be the host.

[mhughes2k]

There is still the zoom privileges side for the admin to deal with. That's a lot of users who either have to give the admin that right or it needs to be automated.

So this a bit different from Zooms schedule for as this would be impersonating the user (by the admin) to create a meeting in the user's name but not requiring that delegation in Zoom.

Which is the same effect as doing a login as and creating the meeting has, just without the explicit change to the user in Moodle (it also has effects on the logging so it's obvious when an action was done by an admin impersonating a user, which is important for security and audit).

The schedule for process on Zoom is their way of delegating meeting creation, I'm not sure we should be short circuiting that process either in Moodle, at least not in a way that is inconsistent with the way that Moodle does actions on behalf of another user.

[mikhail-ict]

@mhughes2k In my current situation – the admin has created all of the users on Zoom. That admin is in control of all of their characteristics. On the Zoom side, the meetings can be easily created for others without the use of schedule_for at all. For mod_zoom to work, I would have to go to each user and assign the admin as a scheduler for them. But this is still a hack, really. Same as on the Moodle side, if I am to use "Log in as".

At the moment the situation is solved though calling Zoom API and then programatically injecting an HTML button to the meeting inside relevant Moodle modules.

[mhughes2k]

I'm not sure it's a "hack" as this is the expected delegation of these rights:-) I agree that there could be a potential quality of life improvement here...(I'm edging towards ideas / implementation questions now, rather than objecting!)

How large an institution are you talking about? To give a counter point, I'm Moodle Admin & a Zoom admin for our institution, but we're pretty large (22k students, 3.5k staff) but our set up is that a lot of these processes are devolved to the teaching & administrative staff within a class so the incidences of a Moodle Admin being the one to set up a teacher's meeting is small, so the overhead of the Moodle login as process isn't particularly big. And with this hierarchy it makes much more sense for the delegation to be limited in scope between the teacher and their admin support.

We also have delegated layers of support staff who look after different areas, and so the don't get full admin rights, but a fairly generous set of capabilties over segments of our Moodle server. This would ideally have to work for that scenario too, not just the Moodle "super" admins.

This would have dictate that it be capability driven, and probably offer this mode if the capability is held on context, but revert to the schedule for mode if not held (ie. both approaches to creating a meeting for another user couldn't be in effect at the same time).

[mikhail-ict]

@mhughes2k It is indeed a valid way of providing delegations, but it is a separate mechanism within Zoom, where non-admin users provide rights for scheduling to other non-admin users, for example. By default, the Zoom owner/admin has that right anyway without extra steps. This is essentially using another similar mechanism in Zoom to gain the rights that are already given only for the purpose of enabling that functionality on the mod_zoom end. I used the word "hack" to describe these extra steps.

We are talking about 600+ graduates each year, only one single school manager and, for the most part, non-technical lecturers. The scheduling is done pretty much by a single person, that faces a manual task of creating 120+ Moodle pages, then creating 120+ Zoom meetings and then manually posting 120+ Zoom links back to the Moodle modules. While observing this, I composed a couple of scripts that automate that process, but this leaves me the only person that can control this Moodle-Zoom environment during the pandemic. Using mod_zoom would be a great addition, though it would involve more manual labor for the school manager, but will provide a perfectly usable solution to the problem and will allow other staff to carry out this task going forward.

Is it possible to observe role_name of a Zoom user and, if matches Owner or Admin, skip verification on the mod_zoom end and allow schedule_for visibility by default? I am trying to think of a shortcut that does not require serious modifications, but rather an exclusion for this specific scenario.

[mhughes2k]

I wouldn't be comfortable (but I guess that would be @jrchamp's call) as it's not really the "moodley" way to do it (and this wouldn't actually affect admin users)

I think it should be more that a mod/zoom:createforuser capability is created, and if a user held that capability on a context (i.e. site, category or course), then this behaviour would be offered, and if they didn't hold it, the regular schedule-for behaviour would be used.

So admins would by default create Zoom meetings for other users (we'd have to give them an option to create for themselves), but we could then delegate that to "power" users over particular categories or individual sites.

Given the Zoom plugin would be working via a JWT that gives them full control over Zoom, we wouldn't need to actually check if the "interacting" admin user is a Zoom Admin....

[mikhail-ict]

@mhughes2k I see what you mean – it is the behaviour of Moodle that defines it, not Zoom.

Am I correct in saying, that there might be a permission created, such as mod/zoom:createforuser, that can be assigned from within Moodle to certain user roles? Then mod_zoom can simply check for that permission and allow schedule_for options?

[mhughes2k]

At the moment we offer the schedule for options to any user (user A) that has a delegated privilege for another user (user B) that is also able to add Zoom meetings to the class they're interacting with (they both have to hold mod:zoom/addinstance), without any further capability check being done, and this is because Zoom already tells us if they can schedule for.

This would have to be (should be) a separate capability & pathway as it would completely by-pass who Zoom says user A can create meetings for and only use Moodle's assertion that User A can create meetings for User B.

Does it make sense for this route to (A) present users (user Bs) that are not members of the class, since they would need to be enrolled in the class to access the moodle activity(?) Or (B) would you expect to be able to create a meeting for a Zoom user who can't see the Moodle activity?

I think in (A) you could offer a drop down list of users (much like current schedule for) whereas for (B) you'd have to just offer an email address input box.

[mikhail-ict]

As you pointed out, in cases for Admin or Owner, there is no way of sourcing the schedule_for list other than accepting that this is true for these role types on Zoom. Though, by knowing that someone is an Admin or Owner, there can be a request to Zoom API to list all users and populate a "schedule_for" list that way without changing the functionality drastically. I am not aware of any potential caveats, so just generating this blindly, sorry.

It would be the first case (A), as a host for a Zoom meeting created for a module is always a teacher/lecturer of that module and admin is not enrolled.

[jrchamp]

@mhughes2k Regarding "my call", I'm not nearly important enough to decide that sort of thing. 😄 @rlorenzo is arbiter of truth here.

If the desire is to grant this functionality to Managers/Local Administrators (as opposed to full Moodle administrators), then a new capability makes a lot of sense and allows some people to turn on the functionality while others reserve it for full Moodle administrators. I think that the email address input box is a simple technical solution, but I also see the benefit of having a list of "users in the course who are viable hosts".

@mikhail-cct It sounds like you want the Manager to be able to create the Zoom activity in Moodle (by giving them mod/zoom:createforuser). When creating the Zoom activity, would it be okay to have the "list of possible hosts" be "users with the mod/zoom:addinstance in this context"?

[mikhail-ict]

@jrchamp Yes, I think your proposal of "list of possible hosts" being "users with the mod/zoom:addinstance in this context" makes complete sense, but even having just the email address input box there would be amazing. Am I correct in saying that, if there are no "users with the mod/zoom:addinstance" enrolled in a module, then no list would be shown, just the the email address input box?

I just realised that the same approach probably will not work with Alternative Hosts, where the email addresses input box looks like the only option.

@mhughes2k @jrchamp @rlorenzo Thank you so much for all your amazing work!

[mrvinceo]

Hi - been lurking here the past day, just want to say this would also be a huge benefit to our organisation. As @mikhail-cct says, the Log in as route works, but is a real pain for a small team when you have year-long courses to set up with a dozen or so lecturers to impersonate per month. Many thanks for looking at this @mhughes2k @jrchamp @rlorenzo !

[mhughes2k]

Am I correct in saying that, if there are no "users with the mod/zoom:addinstance" enrolled in a module, then no list would be shown, just the the email address input box?

In this case don't you have wider issues? :-) You have a course with presumably no one who has a teaching role in it (as most teaching roles tend to inherit the addinstance capabilities)...

[mikhail-ict]

@mhughes2k I am just thinking of a scenario, where mod/zoom:addinstance is removed from a teacher role all together, but a manager with mod/zoom:createforuser can still schedule for teachers. Teachers can still join the meeting through the mod_zoom activity, if they are the host, correct? I can't even start describing how weird things get with non-technical teachers and Moodle/Zoom...

Any chances of having a Web Service for scheduling Zoom meetings with mod_zoom, so the creation can be automated through a script?

[mhughes2k]

Any chances of having a Web Service for scheduling Zoom meetings with mod_zoom, so the creation can be automated through a script?

I always get concerned with a chaining these sort of APIs together as they potentially open security holes.

[mikhail-ict]

@mhughes2k I completely understand.

The reason why I brought it up is because Moodle hosting is outsourced and there is no access to a DB or even the ability for us to install a plugin. The only option is then to create a front-end script through something like Puppeteer that will populate each Moodle module through mod_zoom.

[rlorenzo]

Yeah, if someone can make a patch with a capability that lets them create meetings for other users that have mod/zoom:addinstance capability it would be accepted. That capability should be for Manager roles only. It would need to also filter the list of users to only those that have a Zoom account.

I guess we should also pull out the support for Zoom's "schedule for" since it would not be needed anymore...

Creating a web service to create meetings should be done in another pull request. But that can take in a parameter of who the host should be, to allow scheduling for others.

[jrchamp]

Some organizations may still want the schedule_for piece for users who have delegated access in Zoom and not Manager level access in Moodle. Hopefully we'll be able to overlay the functionality as one interface element since from the user's perspective in Moodle there's no substantive difference.

[mikhail-ict]

@rlorenzo Introduction of a Web Service would solve many problems and its presence can even be critical in some scenarios. Allowing programmatic meetings creation can greatly increase mod_zoom adoption rates.