Page MenuHomePhabricator

Don't send two separate emails when access code applications are approved and sent
Closed, ResolvedPublic

Assigned To
Authored By
Samwalton9-WMF
Sep 10 2020, 9:52 AM
Referenced Files
F34915123: image.png
Jan 12 2022, 5:47 AM
F34913943: image.png
Jan 11 2022, 4:10 AM
F34913951: image.png
Jan 11 2022, 4:10 AM
F34913949: image.png
Jan 11 2022, 4:10 AM
F34912585: image.png
Jan 10 2022, 4:22 AM
F34912589: image.png
Jan 10 2022, 4:22 AM
F33941849: image.png
Dec 10 2020, 12:35 PM
F33941749: 2020-12-10 (1).png
Dec 10 2020, 10:40 AM

Description

Background

There are a number of different authorization methods on the Library Card platform. The access codes method is for the case when we have individual voucher codes or login details that we assign to each editor. When an application is marked as sent, it becomes available in the Send interface for the coordinator to select an access code to assign to it.

We send users an email when their account is approved. We also send them an email when their application is marked as 'Sent'. In the case of access code applications, these two actions can happen very soon after each other - we already have the access codes so there's no need to send the user's details over to some external partner. We can approve their application, and then head over to the Send interface to assign access codes. Ideally, therefore, we should only send the user one email in the access codes case - when their application is marked Sent with the corresponding access code.

Right now, we're not doing that, and the Approved email is confusing. We attempted to consolidate our email sending by merging the logic for access codes with the LINK access method. In the LINK access method we have pre-written instructions for users which can be immediately sent in the Application-approved email. We made the mistake of attempting to do the same thing for access codes; but no access code has been assigned at the point where we send the approval email. As such, users currently receive a confusing email, which tells them to use the "above" access code (there is none) to login. They'll then shortly thereafter receive a separate email which tells them what their access code is.

First email example:

Thank you for applying for access to Ancestry resources through The Wikipedia Library. We are happy to inform you that your application has been approved.

Log in with the credentials above at https://www.ancestry.com/. Upon logging in for the first time, please update your password to something more secure. You are welcome to change the username.

You can view the collections you're authorized to access at My Library: https://wikipedialibrary.wmflabs.org/users/my_library/

Second email example:

Your approved application to Ancestry has now been finalised. Your access code or login details can be found below:

Username: User Password: Password

We need to reorganise the logic for sending these emails so that when a user applies for an access code partner they only receive one email, when their application is marked as sent, that contains all the relevant information.

Application approved email: https://github.com/WikipediaLibrary/TWLight/blob/master/TWLight/emails/templates/emails/approval_notification-body-text.html
Access code sent email: https://github.com/WikipediaLibrary/TWLight/blob/master/TWLight/emails/templates/emails/access_code_email-body-text.html

Users receive user_instructions twice, and we tried to merge the logic for including the access codes, but did so poorly. The approval email is defined in https://github.com/WikipediaLibrary/TWLight/blob/master/TWLight/emails/tasks.py#L319, and get_user_instructions (https://github.com/WikipediaLibrary/TWLight/blob/7a21a98119900f16c028bf1d0db68995134672d2/TWLight/applications/models.py#L302) includes logic for this being a CODES partner.

Acceptance criteria

  • When an application to an access code partner is approved, no email is sent.
  • When an application to an access code partner is marked as sent, with a corresponding access code attached, an email should be sent.
  • The latter email should contain both the access code and any user instructions for using it.

Event Timeline

Samwalton9-WMF updated the task description. (Show Details)

Hi Sam,
I have one doubt, when I change the application status to sent to partners manually from the Django admin I get error.

2020-12-03.png (1×1 px, 197 KB)

So can you tell me how to resolve this or how I can change the application status to sent to partners manually ?

Hi Sam,
The doubt which I mentioned above, is now solved by me.
I have another doubt that, how can I get the email which is mentioned above in task?
When I change the application status to Sent I got this type of mail

2020-12-04.png (1×1 px, 198 KB)

Hi Sam,
Can I work on this issue?

Hi Yash, sure!

When I change the application status to Sent I got this type of mail

Is the partner set to the CODES access method? You'll probably need to go through the motion of going to the 'Mark as Sent' page to test these, since an access code needs to be assigned.

Hi Sam,
I am changing the application status in the way, as I recorded in the video.
I have send that video to you via mail because it was not getting upload on the Phabricator.
Please see that video and tell me that, is it a right way for changing the application status for receiving the email which is mentioned above in the issue?

Is Adler an Access Codes partner?

If so, you need to first Approve it to get the first email, then click 'Send data to partners' in the top right, click Adler, then assign a code to that approved application and click Send. That should prompt the 2nd email :)

When I change Adler application status to approved. I got first email in Django admin in DjMail. Here is the screenshot.

2020-12-10 (4).png (1×1 px, 199 KB)

Then I click to the Send data to Partners and then on Adler. Here is the screenshot.

2020-12-10 (1).png (1×1 px, 158 KB)

After clicking on the Adler. I got this interface.

2020-12-10 (3).png (1×1 px, 179 KB)

After clicking on Sent button. Application status of Adler changed to 'sent to partner'. Then I check DjMail, but I didn't receive second email.

It looks like Adler isn't set to the Access Codes (CODES) access method.

Can you tell me how to check whether the given partner is set to the access code access method Or not set?

Check the authorization method (sorry for using the wrong terminology earlier) for the resource:

image.png (409×373 px, 26 KB)

This comment was removed by Yash4357.

Hi Sam,
I have never use Email in Django.
So it is very new for me. Can you recommend any documentation for the Email which is use in Django?

Hi Sam,
As we don't need first email which is mentioned in the issue which appear when application status is changed to approved, so for that I also need to delete this html file:
Application approved email: https://github.com/WikipediaLibrary/TWLight/blob/master/TWLight/emails/templates/emails/approval_notification-body-text.html

Can I delete this file?

@Yash4357 Just checking in - You asked for some help on your PR quite a while back, and I'm just now circling back around - If you are still interested in working on it and need help just let me know. If you'd like to release the task to let someone else work on it, that would be okay too!

Sorry, for the inconvenience. I am busy in my Gsoc project. So I will not able to work on this task.

Hi @Samwalton9 ! I suppose this issue still persists. Can I work on this?

Hi Sam,
I had a small doubt in the flow of application with partner using access codes for authorization.

Is it the partner who creates the access codes, as for now I am creating it through the admin panel and could not find a url where I can set access code for each application, see below ss once

image.png (1×1 px, 211 KB)

in the above image the access code field comes out to be blank despite the fact that I created an access code object from the admin panel as shown below
image.png (1×1 px, 216 KB)

Hi @Paritosh_Kabra :)

Access codes are assumed to be unique. That means each access code can only be attached to a single Authorization object. In this case it looks like the access code has already been assigned, and therefore it isn't shown in the list of available codes. If you want it to be available in that interface, just remove the Authorization object from the access code.

Hi @Samwalton9 ! Thanks for your clarification, I was now able to reproduce two emails.

I had one more doubt.

The access code is a charfield in the AccessCode model (see below ss for clarity) line 588

image.png (1×1 px, 439 KB)

So is it that the user_instructions field (one more ss below)

image.png (1×1 px, 436 KB)

already specified in the associated Partner model mandates the access codes to be in accordance with them, or there needs to be a seperate instruction field to be created in the AccessCode model for the same.

Reason for this confusion was that the acceptance criteria for this issue separately mentions to email any specific user instructions for the access codes despite the instance.partner.user_instructions are already sent presently (see line 475 in below ss)

image.png (981×1 px, 352 KB)

If I understand your question correctly, the intention of this change is that for access code partners we currently do the following

  • When approved: Send the user_instructions text via email
  • When assigned an access code (marked as 'sent'): Send the access code via email, along with user_instructions again

Instead we want to send both the user_instructions and the access code together in the same email, when the Application is marked as SENT. When the application is marked as Approved - for an access code application - we should not send any email.

You're right that currently, the second email includes user_instructions, I might have missed that when writing the original task description. In this case it might be sufficient to suppress the original 'Approved' email for access codes.

Hi @Samwalton9 Thanks for your clarification! I issued a PR for this issue on github, kindly check it once.

I had one doubt with the checks that CodeQL plugin of github is imposing, and I am unable to figure out the reason for the same.
See the attached ss as reference.

image.png (1×1 px, 266 KB)

Awesome! I'll get this queued up for one of our engineers to take a look at.

I had one doubt with the checks that CodeQL plugin of github is imposing, and I am unable to figure out the reason for the same.

I think because you're a first time contributor to the repository one of us had to approve it running, I've done that now :)

Did a quick check of some recent access code emails and this looks to be working as intended!