send smart reminders after X weeks (default to 2)

mlhess in #2348789: Automate reminders on issues

Sitting longer than 7 for the security team

Sitting longer then 5 days waiting for reporter.

I have a script that does this now. The text to review:

$body = "Hello " . $account->name . ", \n There are security issues awating your action. Please login into security.drupal.org within 2 weeks and provide an update. \n\n";

Each issue is added with

$list .= $projectname . ' -> ' . 'https://security.drupal.org/node/' . $row->nid . "\n";

The final email reads

Hello XXX,
 There are security issues awaiting your action.  Please login into security.drupal.org within 2 weeks and provide an update.

X -> https://security.drupal.org/node/nid
Y -> https://security.drupal.org/node/nid
X -> https://security.drupal.org/node/nid
Z -> https://security.drupal.org/node/nid

'Please login' could start on a new line... But looks good anyway.

I think this looks good. My suggestion is to provide a little bit more in-context explanation as to why we're asking the maintainer to respond within a particular timeframe. The message should:

• Explain the urgency of responding
• Explain the consequences of not responding
• Explain what to do if the maintainer doesn't know how to respond/fix the issue

We should also link to: https://www.drupal.org/node/101497 for a more detailed explanation.

This is just a rough attempt at doing that, likely needs additional finesse from someone on the security team:

Hello XXX,

There are security issues for projects that you maintain that are awaiting your action. These issues are posted to security.drupal.org– a private issue queue for you to coordinate with the security team as you develop a solution for the vulnerability and draft a security advisory.  

Please login into security.drupal.org within 2 weeks and provide an update. If you are unresponsive during this two week period, the security team may opt to publish a security advisory recommending that the affected module be uninstalled.  If you do not feel able to resolve the issue within the two-week timeframe please stay in communication so that the security team can coordinate with you about any additional time you may need. 

X -> https://security.drupal.org/node/nid
Y -> https://security.drupal.org/node/nid
Z -> https://security.drupal.org/node/nid

For more information on your responsibilities as a maintainer contacted by the security team, please see: https://www.drupal.org/node/101497

This is ready to go.

Here is a hacky attempt at providing this in an existing drush file.

Output on my local looks like this:

Hello demo,

There are security issues for projects that you maintain that are awaiting your action. These issues are posted to security.drupal.org - a private issue queue for you to coordinate with the security team as you develop a solution for the vulnerability and draft a security advisory.
Please login into https://security.drupal.org within 2 weeks and provide an update. If you are unresponsive during this two week period, the security team may opt to publish a security advisory recommending that the affected module be uninstalled.  If you do not feel able to resolve the issue within the two-week timeframe please stay in communication so that the security team can coordinate with you about any additional time you may need.

 Project  Issue                                URL
 test     test issue                           https://security.drupal.org/node/2
 test     This is another test security issue  https://security.drupal.org/node/3


For more information on your responsibilities as a maintainer contacted by the security team, please see: https://www.drupal.org/node/101497

Sincerely,
The Drupal Security Team

Added a line break and posting example without code for wrapping

-----

Hello demo,

There are security issues for projects that you maintain that are awaiting your action. These issues are posted to security.drupal.org - a private issue queue for you to coordinate with the security team as you develop a solution for the vulnerability and draft a security advisory.

Please login into https://security.drupal.org within 2 weeks and provide an update. If you are unresponsive during this two week period, the security team may opt to publish a security advisory recommending that the affected module be uninstalled.  If you do not feel able to resolve the issue within the two-week timeframe please stay in communication so that the security team can coordinate with you about any additional time you may need.

 Project  Issue               URL
 test     test issue          https://security.drupal.org/node/2
 test     another test      https://security.drupal.org/node/3


For more information on your responsibilities as a maintainer contacted by the security team, please see: https://www.drupal.org/node/101497

Sincerely,
The Drupal Security Team

Actually don't merge this hack, I've got a much better implementation I'm working on.

I've run into a logic issue with this -

The original idea was a drush script that would itself be run only twice a month. However with that implementation, an issue could be 3 weeks and 6 days old before an email was sent.

So I was moving this to a proper cron hook with a SQL filter to pick issues that haven't been updated in X weeks (2). That way an email would be sent when the issue was actually 2 weeks old.

However I realized that without some sort of marker or change to the issue, the same set of issues would send an email over and over on every subsequent cron run.

Options:

- Put a marker on the issue to indicate a reminder has been sent, or maybe have an automated comment.
- Only run the cron hook once a day, which would send a daily reminder list of all stale issues.
- Only run the actual stale notifications once every 2 weeks.

- Only run the actual stale notifications once every 2 weeks.

Why my thought.

I think putting a marker would be good, but it would be best to have a 'last contacted' field that shows on which date a reminder was sent to the maintainer. That way we would know after what date we would be able to mark the project unsupported.

We can also use automated commenting for the same purpose. The downside of it however is that it generates even more email notifications.

While I was thinking through this (my assumption is that the script only covers #1 "If an issue is in some status that indicates it needs work by maintainers for more than X weeks . . ." ) one question popped up. This may be a 'scope creep', but @cashwilliams does your script re-send the notification if the maintainer initially responds within 2 weeks, but fails to respond afterwards?

Here's what often happens:

1. We receive a report
2. The issue is assigned to the maintainer (issue status: 'Active' -> 'Needs maintainer response')
3. We receive no responses from the maintainer so we send them a notice
4. The maintainer supplies the patch (issue status: 'Needs maintainer response' -> 'Patch (code needs review)')
5. Discussions are held, and the sec team ask the maintainer to respond to our questions or update the patch (issue status: 'Patch (code needs review' -> 'Needs maintainer response' / 'Patch (code needs work)')
6. The maintainer doesn't respond so we send them another notice
7. We mark the module unsupported after not receiving a response from the maintainer for x weeks

If the script sends a notice in the step #2 above, would it re-send another notice at step #6?

Right now the script would send notice in #2 and #6.

The current select is very simple, and filters on:
- status is in a state that requires maintainer action (ie not closed, not waiting on sec team, etc)
- node changed date is older then 2 week (it looks like adding a comment on s.d.o updates the node changed date, so basically 0 activity for 2 weeks)

for the marker idea, we could actually put a comment into the system AND change the status to "No maintainer response (unsupported)" which would show up in our filters when we're looking for tickets on Wednesdays.

Something like attached mockup.

Dumping completely untested patch just to ensure the work isn't lost or anyone wants to pick up.

This is the different implementation I mentioned in #8.