Show correct email for authorization confirmation

[vrajmohan]

🎫 Ticket

Link to the relevant ticket:
Authorization confirmation doesn't show selected email for partner

🛠 Summary of changes

1. Refactored code - added a ServiceProviderIdentity#email_address_for_sharing that does the right thing
2. Added a test to verify correct behavior in SAML
3. Eliminated EmailContext class that seemed to be of limited value.

📜 Testing Plan

Use the "Steps to reproduce" from the Jira ticket.

[kevinsmaster5]

I like how you are using this to simplify things like EmailContext.new(current_user)...etc

[kevinsmaster5]

Looks good and works as expected in bug ticket.

[aduth]

Nice refactors 👍

[aduth]

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?

https://github.com/18F/identity-idp/blob/b5c849eb3f33993a186c7df54926c8917c93d0ca/spec/controllers/accounts/connected_accounts/selected_email_controller_spec.rb#L79

https://github.com/18F/identity-idp/blob/b5c849eb3f33993a186c7df54926c8917c93d0ca/spec/controllers/sign_up/select_email_controller_spec.rb#L76

[aduth]

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.

[vrajmohan]

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?

[aduth]

What would scopes do for us here, or at least specifically in regard to my comment?

[vrajmohan]

We would be explicit when we say user.email_addresses.confirmed.last_signed_in.

[vrajmohan]

Just realizing that I have misunderstood active service provider identities. Fixing...

[aduth]

Can you resolve the merge conflict?

[aduth]

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.

Suggested change

	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.

[aduth]

How are we ensuring last_sign_in_at ordering with this change?

[vrajmohan]

This line by itself does not ensure that. The change to User#last_sign_in_email_address on line 524 does it.

[vrajmohan]

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.

[aduth]

I think a rebase might have gone awry, reintroducing code removed in #11656 (causing build failure).

[vrajmohan]

Yep, saw that! Fixing.

[zachmargolis]

This looks like a scope? Can we mark it as one with

Suggested change

	def self.last_sign_in
	order('last_sign_in_at DESC NULLS LAST').first
	end
	scope :last_sign_in, -> { order('last_sign_in_at DESC NULLS LAST').first }

[vrajmohan]

In my opinion, a "scope" has the connotation of a filter and not an ordering. I followed the example described in the Rails docs itself (see the last couple of sections).

[vrajmohan]

Also, scopes should return an ActiveRecord::Relation or nil whereas we are returning a single object.