Skip to content

LG-12091 Send please call email#9977

Merged
svalexander merged 18 commits intomainfrom
shannon/lg-12091-send-please-call-email
Feb 5, 2024
Merged

LG-12091 Send please call email#9977
svalexander merged 18 commits intomainfrom
shannon/lg-12091-send-please-call-email

Conversation

@svalexander
Copy link
Contributor

@svalexander svalexander commented Jan 25, 2024

🎫 Ticket

Link to the relevant ticket:
LG-12091

🛠 Summary of changes

This pr sends a "Please call" email when a user who has fraud review pending gets passed by usps.

📜 Testing Plan

Provide a checklist of steps to confirm the changes.

  • Verify en strings are correct by viewing preview
  • Use drop down to change language to "es" and verify es strings are correct
  • Use drop down to change language to "fr" and verify es strings are correct
  • Go through ipp flow and arrive at ssn page
  • From drop down select "review"
  • Continue to end of flow and arrive at barcode page
  • In code comment out enrollment_outcomes[:enrollments_passed] += 1 from line 396 of app/jobs/get_usps_proofing_results_job.rb
  • In terminal open rails console rails c
  • Save enrollment e = InPersonEnrollment.last
  • Save json json = UspsInPersonProofing::Mock::Fixtures.request_passed_proofing_results_response
  • Save response res = JSON.parse(json)
  • Update the user's profile e.profile.update!(fraud_pending_reason: 1)
  • Initiate job GetUspsProofingResultsJob.new.send(:process_enrollment_response, e, res)
  • Ensure that the please call email was went

👀 Screenshots

If relevant, include a screenshot or screen capture of the changes.

En:
Screen Shot 2024-01-26 at 3 54 12 PM

Es:
Screen Shot 2024-01-31 at 2 05 15 PM

Fr:
Screen Shot 2024-01-31 at 2 05 30 PM

@svalexander svalexander marked this pull request as draft January 25, 2024 21:05
@svalexander svalexander requested review from a team and carmenrosalop and removed request for a team January 26, 2024 16:38
@WheresHJ
Copy link

WheresHJ commented Jan 26, 2024

There is some bolding missing in the second paragraph, as follows:

Call (844) 875-6446 and provide them with the error code ABCD.

Also not sure why the line break in the second paragraph is so different from the Figma, but it's OK.

@WheresHJ
Copy link

Also, the footer styling is substantially different from the Figma, but this seems to actually be the case in all our emails. Don't think we should fix this here, but might be worth a separate task or investigation @n1zyy

Screen Shot 2024-01-26 at 2 04 14 PM

@n1zyy
Copy link
Contributor

n1zyy commented Jan 26, 2024

Also, the footer styling is substantially different from the Figma, but this seems to actually be the case in all our emails. Don't think we should fix this here, but might be worth a separate task or investigation @n1zyy

Screen Shot 2024-01-26 at 2 04 14 PM

Interesting! My first thought was that this was maybe an issue with the mail preview itself, but it is not. Live mail I've received looks the same.

The core email template is https://github.com/18F/identity-idp/blob/main/app/views/layouts/user_mailer.html.erb for all these.

I agree about splitting that out into a separate ticket from this one. It probably makes sense for our team to pick it up, but FWIW it's the template used by all emails. fe08811 is where the "Sent at" came in.

Copy link
Contributor

@n1zyy n1zyy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really need to get my PR in since I think this is the logical successor to it.

I think instead of your handle_call_in_needed method, we just want to drop your email send into the code I'm adding for handling fraud_pending_reason users who proof. In hindsight the ticket wasn't super clear about this.

But otherwise, this is looking good.

@WheresHJ
Copy link

@n1zyy Yeah, just wanted to flag it while there was an active example. Maybe let's try to track it down and connect with @eryn-sobing in planning.

@svalexander
Copy link
Contributor Author

I think instead of your handle_call_in_needed method, we just want to drop your email send into the code I'm adding for handling fraud_pending_reason users who proof. In hindsight the ticket wasn't super clear about this.

@n1zyy I'll wait to merge your changes into my branch before finalizing this pr


# Tracks please call emails that are initiated during GetUspsProofingResultsJob
def idv_in_person_usps_proofing_results_job_please_call_email_initiated(
**extra
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may fail when merged to main since #9946 was merged and requires explicit documentation for every received analytics argument. I'd suggest merging main or rebasing the branch to make sure that check passes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since it's it's called from within an existing job, it might get a free pass due to allowed_extra_analytics: [:*] on many existing files

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am wondering how I can use a string rather than the method name in track_event() like other analytics events do.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Method name is the expected event name, this is a recent-ish change in process which is why other events log a string.

Related: https://github.com/18F/identity-idp/blob/main/docs/backend.md#analytics

@svalexander svalexander marked this pull request as ready for review January 31, 2024 19:18
@svalexander svalexander changed the title add email ui and preview LG-12091 Send please call email Jan 31, 2024
@svalexander svalexander requested review from a team and JackRyan1989 January 31, 2024 19:20
Copy link
Contributor

@JackRyan1989 JackRyan1989 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great so far! I just have a few small comments and questions that should be fairly easy to resolve. Good job Shannon!

end
end

def handle_call_in_needed(enrollment, response)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: This method name is slightly confusing to me. Could we include 'fraud' somewhere in the name so it's clear it relates directly to fraud?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea, updated to handle_passed_with_fraud_review_pending


def send_please_call_email(user, enrollment)
user.confirmed_email_addresses.each do |email_address|
# rubocop:disable IdentityIdp/MailLaterLinter
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Is there an easy-ish formatting thing we can do so we're not disabling the linter? I feel like that's a bit of a flag.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a custom rule that enforces the use of deliver_now_or_later vs deliver_later. I'd wonder if we should be using deliver_now_and_later to avoid the lint? There are a few cases where we want to ensure it's delivered exclusively now or later, but I'm not sure that applies here.

https://github.com/18F/identity-idp/blob/main/lib/linters/mail_later_linter.rb

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok interesting. Thanks for that info @aduth. Yeah unfortunately I don't know enough about the motivation for enforcing that we do these calls async. This might be a good thing to bring back to our team and see what folks think.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea with deliver_now_or_later is that we'd typically want to deliver messages asynchronously (to avoid blocking the response), but this is controlled through configuration to allow us the option to deliver synchronously if needed in an environment or if there's issues with asynchronous delivery.

See also:

def deliver_now_or_later(opts = {})
if IdentityConfig.store.deliver_mail_async
deliver_later(opts)
else
deliver_now
end
end

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

digging back through some old prs and it looks like we previously made the decision to use deliver_later for the emails sent in this job, pr where we made the switch

Copy link
Contributor

@n1zyy n1zyy Feb 2, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I generally don't like the pattern of rubocop:disable for stuff without a really compelling reason. But, as you pointed out, and as is found in some old Slack threads, there's precedent here: every other mailer call in this file is deliver_later.

So, in the end, unless others object, I would support leaving this as-is. I'd rather the file stay consistent, even if it's not strictly necessary in this case.

@n1zyy
Copy link
Contributor

n1zyy commented Feb 2, 2024

Also, the footer styling is substantially different from the Figma, but this seems to actually be the case in all our emails. Don't think we should fix this here, but might be worth a separate task or investigation @n1zyy

Filed LG-12314 for this so it doesn't get lost.

Copy link
Contributor

@n1zyy n1zyy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for being slow on the update here, but I'm now on Team :shipit: here. Thanks for your patience in getting this story through!

@svalexander svalexander merged commit 759241d into main Feb 5, 2024
@svalexander svalexander deleted the shannon/lg-12091-send-please-call-email branch February 5, 2024 15:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants