Migration Ironwood 3.11.16 to Juniper 10.0.1 w Discovery + Ecommerce - Migration failed, then lms logins failed - workaround

Hello there Tutor users

When I migrated tutor from „in production“ Ironwood (tutor 3.11.16) to Juniper (10.0.1) with the modules discovery and ecommerce. During migration something bad happened to migrations in ecommerce. Afterwards, I had an issue that my lms login worker failed signing anybody in anywhere. However, discovery and ecommerce appeared working in the log files. Once I modded the database (trashing most entries from database ‘openedx’ out of the tables ‘oauth2…’ and ‘oauth…’ parts), discovery and ecommerce broke, but elearning login worked normally

In case you should encounter similar issues, here is my long story short:

  • I had no client side payment processors left in config.yml, ecommerce requires at least one for building, else it will print out an error stating ~ ‚null is not iterable‘. So I set back an empty cybersource payment client side processor. Ironwood was fine without any
  • The login details from oauth2_provider_application for the JWT cookies was used by oauth_dispatch_applicationorganization (I suppose for discovery login) and in my case failed then for the general lmslogin. I suppose it gets blocked out for other services after being called once

I fixed the login issue by adding an additional oauth2_provider_application entry to the database cloning all but the name of the ‚login-service-client-id‘, then referencing oauth_dispatch_applicationorganization to the new id.
Now my tutor page is almost back to normal, I have a price tag on not-yet-published courses and can login again.

So, I inserted a new oauth2_provider_application with the next free id of 11 and named it ‘disco-login-service-client-id’ with the same password as the original ‘login-service-client-id’:

Insert into `oauth2_provider_application` VALUES (11,'disco-login-service-client-id','','public','password','***','Login Service for JWT Cookies',2,0,'2020-06-30 00:00:00.000000','2020-06-30 00:00:00.000000');

My original site fix for logging in and only Breaking disco and ecom was nailed down to the only entry i had in oauth_dispatch_applicationorganization. So, I inserted back into oauth_dispatch_applicationorganization the old entry but referencing the new id from oauth2_provider_application:
Insert into `oauth_dispatch_applicationorganization` VALUES (1,'content_org',11,1);

Before error trapping my database looked like this:

select * from oauth_dispatch_applicationorganization;
+----+---------------+----------------+-----------------+
| id | relation_type | application_id | organization_id |
+----+---------------+----------------+-----------------+
|  1 | content_org   |              1 |               1 |
+----+---------------+----------------+-----------------+



select * from organizations_organization;
+----+----------------------------+----------------------------+---------------------------+------------+--------------------------+----------------------------------------------+--------+
| id | created                    | modified                   | name                      | short_name | description              | logo                                         | active |
+----+----------------------------+----------------------------+---------------------------+------------+--------------------------+----------------------------------------------+--------+
|  1 | 2020-04-18 13:59:12.651275 | 2020-04-18 23:20:26.626942 | MedoPolo Medical Programs | medopolo   | Die beste Firma der Welt | organization_logos/Medopolo-Logo_3kd8DnL.png |      1 |
+----+----------------------------+----------------------------+---------------------------+------------+--------------------------+----------------------------------------------+--------+


select * from oauth2_provider_application where id = 1; --there were 10 entries total
+----+-------------------------+-------------------------------------------------------------------+--------------+--------------------------+----------------------------------------------------------------------------------------------------------------------------------+-------------------------------+---------+--------------------+----------------------------+----------------------------+
| id | client_id               | redirect_uris                                                     | client_type  | authorization_grant_type | client_secret                                                                                                                    | name                          | user_id | skip_authorization | created                    | updated                    |
+----+-------------------------+-------------------------------------------------------------------+--------------+--------------------------+----------------------------------------------------------------------------------------------------------------------------------+-------------------------------+---------+--------------------+----------------------------+----------------------------+
|  1 | login-service-client-id |                                                                   | public       | password                 | *** | Login Service for JWT Cookies |       2 |                  0 | 2020-06-18 02:50:00.250239 | 2020-06-18 02:50:00.250281 |

However! If I restart the entire platform using ‘tutor local restart’ my lms won’t work. Quickstart it, and it is back normally again. This is fine for me for the Moment