Adding Live Meeting to Training

Axel - thanks for your suggestions I'm using the latest 8.x-1.9 distribution (that still has the 8.9.2 Drupal Core) and Moxtra credentials seem to be OK. Have also uninstalled and re-installed Opigno Moxtra module I am able to create a Live Meeting at /admin/content/moxtra/meeting but cannot add anyone else, so Watchdog reports an error: [http_code] => 400 [code] => RESPONSE_ERROR_INVALID_REQUEST [message] => invitee expected Even with the error, I am able to have a meeting with myself (so I can see myself on video within the Moxtra UI inside the LMS), so the Moxtra plugin works. Only piece not yet configured is integration to LRS - this shouldn't have any impact, should it? Still not able to add a Live Meeting to a training.

Thanks for replying Axel (it's great to know you're helping). I should have mentioned that all email addresses have been registered. Now that all relevant user accounts within Opigno have been registered, if I try "register all" again I get the following error "Error while contacting the Moxtra server." in watchdog: [http_code] => 400 [code] => RESPONSE_ERROR_INVALID_REQUEST [message] => email exists at line 1 Not sure what else could be wrong. I might try a fresh re-roll of the distribution

I've rolled a completely new instance of Opigno, added my Moxtra credentials and registered the single user with Moxtra. Looking at my Moxtra dashboard, the new user has been added. LRS has not been configured. There is still no option to add a live meeting via the Learning Path manager. The new instance of Opigno was built locally on Lando using Composer `composer create-project opigno/opigno-composer example-folder` and no other modules have been added. The only errors that I have noted: * Composer did not download or install all files upon initial *create-project* command; had to follow with `composer update` to obtain missing files * Watchdog reports numerous *'Missing text format: basic_html.'* errors during installation. *basic_html* format appears to be configured corrected as part of distribution.

The instance has now been deployed on a 'public' staging server. Lots of errors because email addresses already exist on the Moxtra account, but nothing else that indicates a problem with the config

Every attempt to create a Live Meeting (at */moxtra/meeting/add*) reports 'Email already exists' error `GuzzleHttp\Exception\ClientException: Client error: 'POST https://xxx.moxtra.com/v1/XXX/user?access_token=XXX' resulted in a '400 Bad Request' response: @"code":"RESPONSE_ERROR_INVALID_REQUEST","message":"email exists at line 1" in /vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:113 Stack trace: #0` This is then followed by another error `"RESPONSE_ERROR_INVALID_REQUEST","message":"invitee expected"` because no invitees have been added to meeting request The problems could be related to using the same Moxtra account for multiple instances of a website (eg, local/dev, staging and production). Each Opigno instance is likely to have same email addresses. So is the solution creating different Moxtra accounts for different instances of Opigno? I'll contact you offline about this.

Most of the problem has occurred because Moxtra stores a *unique_id* for each user - this is currently: - An **'m_'** prefix onto the User ID for all those with 'Live Meeting Manager' permissions (eg, 'm_23'). These become 'Internal users' within the Moxtra account - Just the user ID number for all other users. These are stored as 'Clients' within Moxtra The problem I encountered was setting up a local installation of Opigno and trying it out with Moxtra. I then migrated the entire site (including users) to a testing server for wider access. Same credentials for Moxtra, so it would effectively duplicated users with the same *unique_id* values causing a clash. This results in API calls being rejected because the users already exist in the Moxtra client list... So the solution is twofold: 1. Delete surplus accounts from Moxtra (you do this in the Moxtra account admin portal: click on the user (not the checkbox), then the ellipsis that appears in bottom right of screen next to 'Edit Profile'; select 'Delete user', check the boxes...) 2. Next you need to apply a patch (to be released in next issue of Opigno) that applies a unique prefix to the 'unique_id' based on the site URL (rather than the *m_* in the current configuration) The when you next register users via */admin/config/opigno/moxtra* it should re-register users with the new 'unique_id' value, and you wan't have clashes if you have more than one Opigno instance pointing to the same Moxtra account. Check your dblog (*/admin/reports/dblog*) for any HTTP400 responses from Moxtra Other top tip is to re-save your Moxtra credentials at */admin/config/opigno/moxtra* Big thanks to Axel Minck from connect-i and Philip Wing at Moxtra for getting to the bottom of this.