Most of the errors (974) were related to licenses. Second (209) was issues with the downloaded files, probably due to file types.

The above seems to only allow for a generic message. If they want to have a custom one, for instance with their new email address, they need to set it themselves before leaving.

It looks like we can use a group for auto replies: https://bulksignature.com/blog/how-to-set-up-auto-replies-for-departing-employees-on-google-workspace. That way we can have the same message for all previous employees and if we want to update it we only need to change it in one place.

@Viktoria_Hillerud_WMSE, do you remember if there were issues with running MW on less than 4 GB? In T403019 it sounds like the reason we upgraded from 2 GB was that the TTS needed more.

Started declaration job.

Adding up all the declarations from the tasks listed in the description gives a total of 5,049,687. This is in line with what's shown on the statistics page in the explorer. That number includes the 100,000 something declarations made previously.

This one wasn't finished because of the issues mentioned above. It wasn't easy to get useful statistics from the logs due to repeated attempts.

I noticed a weird behaviour when I tested this. If you change the toggle and close the popup, not save, the toggle will have the new (unsaved) state when you open the popup again.

Marking this as done even if there are a few questions around groups still waiting for answers.

Declaration job started.

Task is up for the above: T432592: [jobs-api,jobs-cli] `toolforge jobs load` uses PATCH for one-off jobs too.

Declaration job started.

Looks like this might be something on my end. When I tried in a clean browser profile the permission shows up in the address bar.

When we had a look at this we discovered what looks like a bug in the Permissions API. If you grant a permission temporarily and then refresh the page the permission is no longer shown in the address bar, but it still has state: "granted". At least that's how it works in Firefox.

Nothing that needs to change now, but I suppose that the "recording type" will be set automatically once you can chose that in an earlier step. If so we may want to remove it, though it could still be useful as a manual override.

Looks good.

This might be useful: https://vueuse.org/core/usePermission/. I don't know of VueUse is used already.

Yes. What happens now is that the user are told they'll see something that doesn't appear. Note that this also happens if the user has allowed microphone permanently (which is good). That means you need to actually check permissions and not rely on if they've passed the hardware check. Technically they can also withdraw the permissions, but that's probably less likely.

No, I mean the step that you added.

You're probably right. It's fine as it is. We can revisit this if needed in the future.