Currently, project/project_issue module has three e-mail address fields:

1. project_projects.mail at node/#/edit, which is used for the reply-to on all issue e-mails (possibly about to be blown away in http://drupal.org/node/189210)
2. project_issue_projects.mail_digest at node/#edit/issues, which is used to send a digest of critical mails to a certain e-mail address.
3. project_issue_projects.mail_copy at node/#/edit/issues, which is used to send a copy of every issue fulfilling certain criteria to a certain e-mail address.

Does it make sense to merge 3 of these fields (or possibly 2) into one field that's specified where the project_projects.mail address is (used to be)?

I ran the following query on drupal.org (projects.drupal.org didn't work because of the e-mail address munging):


$result = db_query("SELECT p.nid, n.title, u.name
FROM project_projects p
INNER JOIN project_issue_projects pi ON p.nid = pi.nid
INNER JOIN node n ON p.nid = n.nid
INNER JOIN users u ON u.uid = n.uid
WHERE (pi.mail_copy != '' AND p.mail != pi.mail_copy)
OR (pi.mail_digest != '' AND p.mail != pi.mail_digest)
ORDER BY u.name, n.title
");

echo "Total: ". db_num_rows($result);

$links = array();
while ($row = db_fetch_object($result)) {
$links[] = l($row->title, "node/$row->nid") . ' ('. l($row->name, "user/$row->uid") .')';
}
echo theme('item_list', $links);

and it came up with 180 results, out of 2300-some projects. I wonder though how many are using this feature intentionally, vs. how many changed their e-mail address in one of the places and forgot about the other.

Comments

dww’s picture

dww
we/he/they
commented

1) Not just possibly, will definitely be blown away in the near future. ;)

2) I could imagine sites where there's a mailing list for manager types that gets the critical issues digest, but they don't want email for every issue or comment.

3) It's weird that this setting is different from just subscribing to the issue queue using the regular email subscription functionality. However, this setting is better, since you can filter it to exactly what components/states you want. It's lame that the usual subscription interface doesn't provide that flexibility. :( If you wanted to do something useful here, I'd say it'd be to improve the regular subscription interface to provide the same flexibility, and then remove this setting entirely (with an upgrade path to convert any existing settings into true subscriptions.

Issue subscriptions needs a lot of help, so check out http://drupal.org/node/161850, in particular, http://drupal.org/node/161850#comment-584667 (comment #2) for more. Also, chx has apparently re-written the subscriptions module from the ground-up: http://www.drupal4hu.com/node/91 and we might be able to build upon that work for our subscription needs in the future, instead of doing it all ourselves in project_issue...

Also, I'd prefer *not* to pollute the node/N/edit tab with issue-related settings. That's what the "issues" subtab is for. It's a bug that the setting #1 is on node/N/edit in the first place (thankfully, we're just going to remove the setting entirely, instead of moving it).

dww’s picture

dww
we/he/they
commented

FYI: if you care about these settings, please see http://drupal.org/node/189843

dww’s picture

dww
we/he/they
commented
Title: RFC: Merge the 3 e-mail address fields into one? » RFC: Merge the 2 e-mail address fields into one?
Status: Active » Closed (works as designed)

http://drupal.org/node/189210 is now fixed, so we're down to 2 email settings, both on the same subtab, but each with different functionality. As I pointed out in #1, I can see a valid use-case where you don't want these to go to the same place. So, I'm going to call this "by design". Honestly, both of these should go away in favor of more flexible and powerful subscription functionality available to all users, not just project owners. Why are only the owners able to get a monthly critical digest? Lame. But the solution isn't to merge into a single, uber-address, it's to make the per-user subscriptions better so we can just remove these settings from the project node entirely. But that's a different story, which belongs in a different issue.