-
Notifications
You must be signed in to change notification settings - Fork 116
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Show correct email for authorization confirmation #11667
base: main
Are you sure you want to change the base?
Conversation
614c31a
to
b5c849e
Compare
def last_sign_in_email_address | ||
confirmed_email_addresses.first | ||
end | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like how you are using this to simplify things like EmailContext.new(current_user)...etc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good and works as expected in bug ticket.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice refactors 👍
def email_address_count | ||
user.email_addresses.count | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think these stubs were valid anyways, but might have been trying to refer to this method now removed and we could remove the stub as well?
identity-idp/spec/controllers/accounts/connected_accounts/selected_email_controller_spec.rb
Line 79 in b5c849e
allow(user).to receive(:email_address_count).and_return(2) |
allow(user).to receive(:email_address_count).and_return(2) |
app/models/user.rb
Outdated
def last_sign_in_email_address | ||
confirmed_email_addresses.first | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar comment about test coverage in spec/models/user_spec.rb
. I'd be specifically concerned to have regression coverage in how we rely on confirmed_email_addresses
to be ordered here, which I wouldn't think is a given.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO, it would be better to use scopes as shown at the end of https://api.rubyonrails.org/v8.0.1/classes/ActiveRecord/Scoping/Named/ClassMethods.html#method-i-scope. Should I go ahead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What would scopes do for us here, or at least specifically in regard to my comment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We would be explicit when we say user.email_addresses.confirmed.last_signed_in
.
e17819d
to
be8d297
Compare
Just realizing that I have misunderstood active service provider identities. Fixing... |
be8d297
to
4aa4f42
Compare
Can you resolve the merge conflict? |
context 'when an email address for sharing has been set' do | ||
it 'returns the shared email' do | ||
identity.email_address = shared_email_address |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor: I might expect the assignment here to happen in a before
block so that if we added additional test cases to this context, each would have the same common behavior of "sharing has been set" without having to duplicate the code. Similar to what we're doing with feature flag enabling.
context 'when an email address for sharing has been set' do | |
it 'returns the shared email' do | |
identity.email_address = shared_email_address | |
context 'when an email address for sharing has been set' do | |
before do | |
identity.email_address = shared_email_address | |
end | |
it 'returns the shared email' do |
Same comment applies for context
block below this.
app/models/user.rb
Outdated
email_addresses.where.not(confirmed_at: nil).order('last_sign_in_at DESC NULLS LAST') | ||
email_addresses.confirmed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How are we ensuring last_sign_in_at
ordering with this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This line by itself does not ensure that. The change to User#last_sign_in_email_address
on line 524 does it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After further discussion with @aduth, we decided to leave the sort order in, even though the tests pass. We plan to clean this up in a separate PR.
Avoid duplicating logic in OIDC and SAML changelog: Upcoming Features, Partner account, Select email to share with partner
4aa4f42
to
7d8fc14
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think a rebase might have gone awry, reintroducing code removed in #11656 (causing build failure).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, saw that! Fixing.
Clean this up in a separate refactoring
7d8fc14
to
b83e589
Compare
🎫 Ticket
Link to the relevant ticket:
Authorization confirmation doesn't show selected email for partner
🛠 Summary of changes
ServiceProviderIdentity#email_address_for_sharing
that does the right thingEmailContext
class that seemed to be of limited value.📜 Testing Plan
Use the "Steps to reproduce" from the Jira ticket.