email the site admin when new releases are available

commenting to track - a definite +1 from me for this suggestion :) Its a really useful module already - but telling me when to go look would be even better.

+1 ...

and provide a "single-click upgrade" link in the mails so the CVS fetch can be done...
(attention for cvs merge conflicts for core patches!)

As far as I understood it - the releasemonitor module could do CVS - but this module is based on the drupal project module info (that is - release versions/nightlies only) ?

Oops - didn't read the note about modifying the title. Sorry

My suggestion with regard to this (and to prevent duplicating code) is to wait for http://drupal.org/node/63881 to be in core.
This way, when the "update available" is logged into the watchdog log, you can send yourself an email/sms/jabber etc message.

For d6 version, I agree with using watchdog() or possibly the choice of setting up an action. Sending an email seems unnecessarily constrained.

Restrict the amount of messages. One message when an update becomes available or better weekly/monthly consolidated messages. Daily/hourly emails would do more harm than good. When maintaining multiple sites with plenty of modules each would turn this well intended messaging system into a real mail bomb. Further my customers (and I) do not want to update the website with each and every new module version. And therefore do not need to be bothered with each new update.

The problem is, it gets incredibly complicated, quickly, once you try to remember which notifications you've already sent. That's why daily is so easy: we just fetch the new data, call the function to compare with what you've got, and if there are any out of date modules, we invoke the action (be that true actions support, hard-coded email, whatever).

If we're trying to be fancy and only notify once, this becomes much more difficult. Complications include:

1. Say 'foo' and 'bar' need an update, and we invoke the notify action for them. Do we set separate variables for "notified_foo" and "notified_bar"? What happens if foo-5.x-1.4 comes out as a security update and we need to notify again? Seems like we'd have to store "notified_foo_5.x-1.3" in the first place, so that if foo changes again, we notify again.
2. If 'foo' and 'bar' are still out of date, but now 'baz' is stale, do we just notify about 'baz', or send another notification about all 3?
3. How do we safely garbage collect all these older variables to remind us what we've already notified?

I could probably keep going, but you get the idea. None of this is impossible to solve, but it's going to add a lot of code, and I don't think it's worth it. My current proposal for D5:

• Add a new textfield on the settings page to specify a comma-separated list of email addresses to notify.
• In hook cron, if we just refreshed the data, compare for new releases. The existing Warning threshold would work, so if you said you only want warnings for security updates, that'd work here, too. If your site is going to warn you, then check the email setting and if it's not empty, generate an email with details about out-of-date modules on your site.

This would be a relatively small patch, but it has the following benefits:

1. Reuses 2 existing settings to control how "loud" update_status will be: "Warning threshold" and the "Check for updates" frequency. If you only check weekly, you'd only get weekly emails if you ignored them.
2. Sites can opt-out by not providing any email in the new setting. Rather, they have to opt-in for the emails if they want them.
3. This has a reasonable chance of getting done before 5.x-2.0, and therefore, D6 core.
4. It doesn't require any external dependencies.

When porting to D6 core, as soon as the Actions patch lands, we can action-ify this process. Either way, we should probably add a watchdog() there, too. And both of those will give you vastly more flexibility. But, IMHO the above is a totally reasonable approach for 5.x-2.0.

I think dww's plan for now is good. Email would be a great feature and I think keeping it simple at this point makes the most sense. +1 for email field sent out according to update interval selected.

Includes email and watchdog(). Newline-separated textarea on the settings tab. Validation callback. New private helper called from update_status_cron() to invoke hook_requirements and send all desired notifications. Tested locally and all the watchdog stuff is cool, and devel.module says the email was sent, but this needs better testing with real email.

Oh, the one hidden gotcha with this patch is that users with only 'access administration pages' can see watchdog() logs, but sites might not want everyone with 'access administration pages' to know if the site is out of date, insecure, etc. :( You need 'administer site configuration' to see the status report, available updates report, modules page, etc. I have no idea what to do about this, other than rip out the watchdog() calls, but that seems like a shame. Any suggestions?

Ok, given the badness of watchdog() access i mentioned above, here's a simpler version of the patch that always watchdog()'s the same generic message to the 'update_status' log type, with a link to the status report:

"Fetched data on all available new releases and updates."

This simplifies the logic in _update_status_cron_notify() quite a bit, too. ;) It's a shame there's no better solution, but I think this is the safest. Wish there was a way to do per-message (or per-subsystem, or per-severity) ACLs on watchdog messages, but it doesn't look like that's possible in D6, either. :( Oh well, the drop is always moving... maybe someday. ;)

Re#8 I agree that this is the way to go for 5.x-2.0. I knew what I asked and am aware of the difficulties realizing my ideal picture. Lets roll this and see how we can proceed from here.

Patch on #10 tested on a real site with real mail. All worked as advertised. One email address, multiple addresses, with/without warnings, daily, weekly (slightly speeded up of course).

Committed a slightly modified version of #12 to HEAD. I moved the generic watchdog() call out of _update_status_cron_notify() and directly into update_status_refresh() so that we always log whenever we fetch, not just via cron.

Small follow-up commit: http://drupal.org/cvs?commit=71658