Automatically scheduling zoom talks and sending keys

[everthemore]

No description provided.

[akhmerov]

BTW, here the code for talking with zoom can be copies almost completely from #5

[akhmerov]

Let's separate issues, and implement host key rotation separately (I'm looking into that). We'll arrange the sending at a later stage.

[akhmerov]

• Since the speaker isn't actually the talk host, we should also register the speaker when creating the zoom meeting.

Also if the meeting is configured to send an email upon registration, then participants registered via API will receive a registration confirmation, resulting in the speaker getting 2 emails: one with the host key, and another one with their join URL.

As a workaround we can create the meeting with registrants_email_notification = False, and then set it to True after registering the speaker.

Alternatively we can register the speaker with a wrong email. That's faster, but less classy.

[akhmerov]

@everthemore I pushed the implementation of host key rotation to the repo. host_key_rotation.host_key(timeslot: datetime.datetime) generates the key for a specific time slot.

[akhmerov]

cron runs aren't on yet, but I checked that key updates work.

[akhmerov]

@everthemore the keys are fully in place, and should be easy to reuse. Let's get this one going now.

[akhmerov]

I also put some reusable zoom functionality into common.py

[everthemore]

@akhmerov I added the 'add talk to researchseminars.org' file here too, since it makes sense to do so as soon as the zoom link has been registered.

The code is WIP, meaning that most likely some of the YAML fields are incorrectly named atm. I will fix this before we start testing of course. There are a few places in the code that I would like input on, I'll highlight them in review.

[everthemore]

Closes #20

[everthemore]

I have a temporary bit in there that prevents updating of the yaml file with talks, for the first few tests

[akhmerov]

Plan:

• Temporarily switch to use a testing branch as a source of talks yml
• Mock-up the yaml file with testing issue numbers and our emails instead of speaker emails
• Implement speaker registration
• Implement email responses
• Implement issue responses
• debug so that it runs on the test branch
• switch to production
• run it

[everthemore]

• Implement email responses

What did you have in mind here? Should this instead be done by the host-key rotator?

[akhmerov]

Should this instead be done by the host-key rotator?

No, that one runs on schedule and doesn't know whom to contact. We should of course reuse the function that generates the host key for a given time slot, but call if from this workflow.

[everthemore]

Use mailgun?

[everthemore]

@akhmerov Zoom link for meeting is missing, and I'm sure other things are not up to standards. Hopefully I can tweak from here.

[everthemore]

Like adding the time slot to the email

[everthemore]

@akhmerov Merge for testing?

[akhmerov]

My linter catches a bunch of things, let me fix those first.

[akhmerov]

I propose to disable research seminars registration at first: it's easier to debug one thing at a time. Plus authorization is missing in one of the function signatures. Other than that I think good to merge and debug.