Rename Ryerson University to Toronto Metropolitan University

[camdendotlol]

What this PR does

This PR renames all assets in preparation for the move from ryerson.covecollective.org to torontomu.covecollective.org due to the institution's name change.

Notes

• The banner image prominently displays TMU's old name and logo. I imagine they would prefer to update the image, but that would be a self-contained change that we can do at any time during or after the migration process.
• I would also want to check with the tenant if they prefer torontomu.covecollective.org as the URL. I matched their official website, torontomu.ca, but it still seems a bit unwieldy.

Database migration

This PR will remain a draft until we are ready to carry out the migration. There are a couple steps in the process that will have to be done either in the Rails CLI or in a Rake task.

My idea for this name change process is:

1. Put prod into maintenance mode. This is necessary because the Ryerson tenant will briefly be broken between the deployment of this PR and the database updates.
2. Merge and deploy this PR.
3. Rename the tenant and relevant config parameters in the COVE admin site.
4. Rename the tenant database from ryerson to torontomu as per these instructions: https://stackoverflow.com/a/34285885 As far as I can tell, this can only be done directly in Postgres, but maybe there is a way to handle it in the Rails CLI. Note: This step is not strictly necessary, if time is an issue - as the DB name is not user-facing, we can keep ryerson, but it would be preferable for our DB name to match the tenant name. Not applicable because our tenant system is set up differently.
5. In the Rails CLI, switch to the torontomu tenant and update the list of users so @ryerson.ca is replaced with @torontomu.ca in all users' email addresses. This will be done with a temporary Rake task. Note: some older accounts use @english.ryerson.ca or @ryerson.ca, which will also need to be accounted for!
6. Take COVE out of maintenance mode.
7. Change the website URL in Google Analytics (since the site's GA code will stay the same, GA will automatically carry over the stats).
8. NB: Annotations are loaded based on the URI of the document, so if the document URI changes, the annotations have to be changed as well. So we'll have to do a bulk update of annotations, something like: find all annotations matching old hostname, update to match new hostname. See step 5: matching annotations can be found in MongoDB Atlas by searching with {user: {$regex : "ryerson"} }.

Of course, there's plenty that can go wrong in this process, so I would want to test it on staging first.

SAML

We will also need to migrate the SAML configuration. On our end, we would just need to replace the IDP SSO Target URL value with their new one. TMU would need to change their configuration to point to torontomu.covecollective.org. In theory, this should be a lot simpler than setting up SAML for a new tenant, but it all depends on how responsive TMU is when I reach out to them.

Estimate

These changes should take 4-6 hours, but the SAML configuration is a bit of a wildcard.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[camdendotlol]

Some more notes:

• a lot of users already have @torontomu.ca email addresses. I assume a find/replace for @ryerson.edu won't affect that.

[camdendotlol]

New plan

1. Run the email address migration stuff first (replace "@ryerson.ca" with "@torontomu.ca" in the users table as well as the Mongo database). There's no reason to do this simultaneously with the URL changes, so let's knock it out and make sure it completed successfully before moving to the next step. (Our contact confirmed that it's safe to do a simple string replacement on email addresses) Also update annotation URLs from ryerson.covecollective.org to torontomu.covecollective.org.

1a. I remember seeing some variant email addresses such as "@english.ryerson.ca" but I couldn't spot them in the list today. After the main part of step 1, I would like to do a quick check for those and maybe manually update a few if they show up

2. Create a stub tenant at torontomu.covecollective.org and have the TMU people configure SAML setup for that domain. Once they've done that, remove the stub tenant and point the ryerson tenant to torontomu.covecollective.org

2 (alternative). If it's possible to point multiple domains to the same tenant, I could just add torontomu.covecollective.org to the ryerson tenant instead of creating a stub tenant. Going by the admin panel, I imagine we could get multi-domain working by creating two tenant records with the same "DB Name" field.

This plan should entirely prevent downtime, for TMU students and for COVE as a whole, but it might be safer to go into maintenance mode for step 1.

Once everything else is done, there should be a redirect from ryerson.covecollective.org to torontomu.covecollective.org. If that's not possible, we could at least use the welcome_blurb to tell users to switch to the new domain.

[jamiefolsom]

@camdendotlol this looks good. couple of notes:

1. User and Data Updates

   • When we change user emails, it will cease to be possible for those users to log in, or at least they will have to reauthenticate to get in.
   • When we change annotation userid values (email addresses in annotations), only users whose emails match will see their annotations.
   • Therefore, regardless of sequence of these two moves, users won't see their annotations until both that and the annotation change are completed, AND, I think, until they've reauthenticated.
   • That argues in favor of using maintenance mode for these steps.

2. Tenant Update

   • Creating a dummy tenant will require DNS updates, which take time, and could prolong this process, especially if we do more than one in quick succession.
   • I think we can point two domains at the same tenant, actually, so let's go that route if it works.
   • Redirect: Definitely. Would you research how best to do this on Heroku, and via DNSimple?

3. Overall Process

   • If practical, we should dry run this on staging, whether against their live IDP, or against a test IDP if they have one.