Improve ClassLink auth option handling - #75710
Open
carl-codeorg wants to merge 3 commits into
Open
carl-codeorg wants to merge 3 commits into
carl-codeorg wants to merge 3 commits into
Conversation
…2 options A ClassLink user can hold two records for one identity: a v1 record keyed by ClassLink's UserId and a v2 record keyed by "<TenantId>|<SourcedId>". Sign-in keeps both on purpose, so users migrated to v2, or whose district enabled OneRoster after they signed up, saw two "ClassLink Account" rows under "Manage linked accounts". Add Queries::User::LinkedAccounts, which lists one ClassLink record: the newest v2, or the v1 when no v2 exists. The edit view uses it in place of the raw options. Since the listed row now stands for every ClassLink record, disconnecting it removes all of them. Removing only the listed record would leave the hidden one, so ClassLink would still show as connected and the next sign-in would rebuild the v2 record. Primary contact replacement covers the case where the hidden record was primary. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
carl-codeorg
marked this pull request as ready for review
October 2, 2026 04:12
Contributor
|
Should we extend this to Clever too? We should have a bunch of teachers with v0/nil and v3 Clever auth options post Clever v3 migration that are in the same state, showing duplicated Clever linked accounts. |
Contributor
Author
Yep this slipped by me. I thought we had removed the v0 Clever auth options, but this isn't the case. I'll modify this PR to include Clever. |
Clever is in the same position as ClassLink: a user migrated to the v3 API holds a pre-v3 record (nil version) alongside a v3 record, and both showed as separate "Clever Account" rows under "Manage linked accounts". Generalize Queries::User::LinkedAccounts over a table of providers and their preferred version, with Clever preferring v3 as ClassLink prefers v2. Disconnect uses the same table, so disconnecting the one Clever row removes every Clever record the user holds. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The table lists providers whose records carry a version, and the predicate asks whether a credential type is one of them, so name both for that rather than for the collapsing they drive. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
carl-codeorg
force-pushed
the
fix/classlink-options
branch
from
October 2, 2026 21:21
e55a786 to
d0bb668
Compare
nicklathe
approved these changes
Oct 2, 2026
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ClassLink auth options are unique because we support two different versions. There are a couple of legit scenarios where users will have both: they pre-dated the v2 auth option migration, or their district originally didn't support OneRoster, then later turned it on. Users created for districts without OneRoster would have nil-version auth options, then after signing in with OneRoster support, they would get a v2 auth option. For these users we don't actually want to surface two auth options on the account settings page, since this is just one login method to the user. This PR does two things:
Before:
After:
Links
Functionality from PR #75478 will need to be updated to match once this is merged in.
Testing story
Deployment notes
Privacy and security