As a Dataverse user, I want automated emails to include contact info so I can reach out for more info.

[dlmurphy]

Currently, automated emails from Dataverse do not include contact information. Let's automatically include this info in all automated emails, so users can know who to reach out to if they're confused, if they received the message in error, or if they just want more information.

This issue was inspired by Gary's recent report in our Slack:

All emails that go out (especially the automatic ones) need to have contact info at the end of the signature. if it is going to the wrong person, that person needs to have someone to respond to. we can’t assume, as this message does, that we are always right in who the email is going to. please fix this and let’s look for other examples of this. thanks

[...]

i’m not sure which contact it should be. but let’s make sure that every automated email we have has someone to contact. at least an email address

Here's the example screenshot he included, showing an automated Dataverse email as it looks currently:

[dlmurphy]

Spoke with @scolapasta and @djbrooke about this. We'd like to include text at the end of every automated email that dynamically includes the contact email address of the installation sending out the email.

In a new paragraph after the main body of the email, the message could read:

If you believe you have received this message in error, you may contact us at [Dataverse installation support email].

or, if we want it to be more general:

You may contact us for support at [Dataverse installation support email].

[pdurbin]

I just created pull request #4567 and dragged this issue to code review at https://waffle.io/IQSS/dataverse

While I was in there, I noticed that we are signing the emails with the brand of the installation of Dataverse rather than the support email name. For example https://dataverse.lib.virginia.edu uses a support team name of "Libra Data Support":

So while we are in this part of the code, we could change the closing from

Thank you,
Libra Data

to

Thank you,
Libra Data Support

I think having the email come from a support team (Libra Data Support) sounds friendlier than having it come from the brand of the installation (Libra Data) but I didn't want to make this change without talking about it first. I did go ahead and leave a comment in the code about this.

[pdurbin]

I chatted with @mheppler after standup and he likes the idea of using the support team name (i.e. "Libra Data Support") in the closing so I'll work on that. We also decided that whatever appears in the "from" such as "Harvard Dataverse Support" (this is the support team name) should match what's in the closing. This would be more consistent. As of last summer, this wasn't consistent:

[pdurbin]

Ok, in a0740c9 I made the "from" and signature consistent. They are now both the support team name. In the example below I set the support team name using the example from http://guides.dataverse.org/en/4.8.6/installation/config.html#systememail ...

curl -X PUT -d 'LibraScholar SWAT Team <support@librascholar.edu>' http://localhost:8080/api/admin/settings/:SystemEmail

... then I generated a welcome message. Note in the screenshots below that you now see "LibraScholar SWAT Team" in both the "from" and the closing:

(To make this example a little more real I probably should have changed the name of my root dataverse from "Root" to "LibraScholar".)

While I'm uploading screenshots I'll say that we could refactor this part of the code base if we want to increase our code coverage. All the red lines below are not tested by JUnit:

[pdurbin]

Meh, I took a quick swing at refactoring this code but it's a little hairy and makes this issue no longer a "1" so I'm stepping away.

@mheppler stopped by and we discussed how technically we could just add "or just reply to this email" since the email comes from the support address. I'll leave the wordsmithing to others. The code is now dynamic and included the support team's name and email address so if someone wants to adjust the wording it's just a matter of playing with notification.email.closing in Bundle.properties and updating testEmailClosing in BrandingUtilTest.java.

[mheppler]

While looking to compare emails for this issue and issue #1916, @kcondon set up dvn-build with the 4541-support-email branch for me to demo. Noticed there were a few issues, which I have highlighted in bold below.

Test case for replication...

1. Logged into existing account on dvn-build for Tom Brady tbrady12@mailinator.com (don't worry, he's cool with me posting his email in GitHub)
2. Created new "Tom Brady Dataverse", created new "New England Patriots Playbook 2017-2018" dataset with restricted files, enabled request access, published everything -- Tom received automated system emails for dataverse created, dataset created, assigned a role, dataset published
3. Logged into existing account for Bill Belichick on dvn-build, browsed to Tom's dataverse...
4. Sent email from Contact btn on dataverse -- no email was received by Tom
5. Sent email from Contact btn on dataset -- no email was received by Tom
6. Sent email from Contact btn on file -- no email was received by Tom
7. Requested access to first restricted file on dataset pg -- Tom received automated system email for access requested
8. Requested access to second restricted file after navigating to file pg -- Clicking the "Request Access" btn on file pg did nothing, appears broke, no email was received by Tom
9. Tom granted access to first restricted to Bill -- Bill received automated system email for access granted

[mheppler]

Testing on demo (v. 4.8.6 build 146-874a944) and confirmed email for publishing a dataset work as expected, email sent via the contact btn on dataverse pg never appeared in the contact's mailinator inbox.

[scolapasta]

@mhepppler are you sure that the email is being set in the contact email metadata field?

The form isn't sent to a user by role but by what's in that field.

[mheppler]

@scolapasta the required/pre-filled contact fields are correctly set for both the dataverse and dataset.

Also, sat with @djbrooke and confirmed that this contact btn bugginess is not on production (v. 4.8.6 build 146-874a944) -- which I guess suggests it could be a set up issue since it's the same build as demo...??

[kcondon]

OK tested the automatic emails and also confirmed they are working so this ticket should be closable. The other issue, contact dv owner, is preexisting and likely a config issue involving email servers not wanting to forward email with a from address not in email server domain.

Merging this issue and other issue should be worked on separately.

[pdurbin]

Phew! I'm glad things aren't horribly broken. I would have been surprised if they were!

[mheppler]

The email issues that I found on dvn-build and demo could be explained by existing issues. If not, we can create a new issue to resolve them.

• Documentation: add recommendation that jvm-option and :SystemEmail options match to avoid spam filters Documentation: add recommendation that jvm-option and :SystemEmail options match to avoid spam filters #4210
• Request access for restricted files with terms not working from the file page Request access for restricted files with terms not working from the file page #4554