This avoids two errors that we found when running the
data fixups in beta.
1. Site admin developer keys have a nil account.
When we have a dev key with a nil account_id, create
an Lti::Registration and set the account to
Account.site_admin. Previously, we would throw an error
if the account was nil.
2. DevelperKeyAccountBindings *can* be in non-root accounts.
That is to say, the backend allows it, validation-wise. This is
probably something that has been done a few times through
the API unintentionally. When we find a DeveloperKeyAccountBinding
for a non-root account, we should just skip trying to create
an Lti::RegistrationAccountBinding for it.
(Lti::RegistrationAccountBindings must be in a root account.)
Note: in lib/data_fixup/create_lti_registrations_from_developer_keys.rb,
the registration_values hash now has an account_id key instead of
just "account." This is because if the account_id is set to an ID
that doesn't match an account, developer_key.account will be nil,
even though developer_key.account_id is set to some integer. (If
it's a site admin key, developer_key.account_id is nil, and therefore
developer_key.account is also nil. But that's different from having
developer_key.account == nil because the account_id couldn't be found.)
If developer_key.account_id is set to a nonexistent account ID, then
developer_key.account is nil, but the developer key is *not* a
site admin key.
We still want to throw an error if developer_key.account is nil *if*
and only if developer_key.account_id is *not* nil. I.e., the account
is nil and it's not because it's a site admin key.
During the fixup on beta, we did run into a few where
developer_key.account_id was set to a nonexistent account.
test plan:
- specs pass
refs INTEROP-8501
refs INTEROP-8502
fixes INTEROP-8800
flag = lti_registrations_page
Change-Id: Ia3198b21e2b29b5cb9ac75b5f9cbabf492e620f2
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/355019
Reviewed-by: Xander Moffatt <xmoffatt@instructure.com>
QA-Review: Xander Moffatt <xmoffatt@instructure.com>
Product-Review: Tucker Mcknight <tmcknight@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
1c075e1f0f