Remove per-project email notification functionality for D7

Based on an IRC chat with tvn, we agreed C should die (for now):
#700616-6: Add a way for users to opt-in for reminder emails about open issues per-project

Still trying to figure out what to do about A and B...

Re: B... this is somewhat interesting:

mysql> SELECT count(pip.nid) FROM project_issue_projects pip INNER JOIN multiple_email m ON pip.mail_copy = m.email WHERE pip.mail_copy != '';
+----------------+
| count(pip.nid) |
+----------------+
|           1294 | 
+----------------+
1 row in set (0.05 sec)

So, most of the 1784 total users of this feature are just pointing to an email address that's already someone's actual email address (and in 1098 of the cases, it's the email in {users}.mail -- the primary email for the account). There are only 491 cases where this points elsewhere.

I obviously can't paste those email addresses here, but it's an interesting mix. In a lot of cases, it's clearly some Drupal shop's "development" or "devteam" mailing list/alias. In some cases, it's just some random gmail account that's neither in {users}.mail nor {multiple_email}.email (e.g. another account someone (presumably) controls that they didn't bother to register as an official address for their account). In 45 cases, it's a user+something@gmail account...

Anyway, I suspect a lot of this could be solved if we had #1966218: Infrastructure to support organization accounts and let organization users subscribe to issues, too. I know the user+something@gmail crowd likes doing it that way, but they could almost certainly achieve the same filtering based on the subjects of these emails, so I'm not too worried about that. The random other address case could either be ignored (tell them to use primary) or solved via letting users control which of their multiple emails they wanted their issue notifications to.

So, I lean towards killing B with the understanding that #963704: Add ability to subscribe by component (or filters more generally) should be solved Soon(tm).

Just wanted to record all this data here for now. Still not actually making a decision...

Some more stats:

mysql> SELECT COUNT(nid) FROM project_issue_projects WHERE mail_copy_filter_state LIKE '%1%';
+------------+
| COUNT(nid) |
+------------+
|       3327 | 
+------------+
1 row in set (0.03 sec)

mysql> SELECT COUNT(nid) FROM project_issue_projects WHERE mail_copy_filter LIKE '%1%';
+------------+
| COUNT(nid) |
+------------+
|          0 | 
+------------+
1 row in set (0.03 sec)

So, a lot of projects filter by state, but not a single one filters by category. ;)

Anyway, I'm fine with killing all of these for now in the interest of getting the port done. However, I highly doubt there are generic solutions for these features in other modules, short of something like Rules (which we already ruled out).

Assigning back to myself to actually clean up the remaining references to these features in D7 -- stay tuned.

http://drupalcode.org/project/project_issue.git/commit/3e4eaa9 removes the last traces of A and B from the 7.x-2.x branch. If/when we want any of this functionality, we can re-add it in a sane way.

Thanks,
-Derek

p.s. tvn and I just started a Google doc for the d.o D7 upgrade FAQ so we can record stuff that end-users might need to know after we launch. I added an entry for this, so we'll remember to notify people that they need to subscribe themselves if they want this functionality to continue.