Automatically subscribe users to issues in their project on node creation

+1. I totally do this with every project, forget that I have to manually subscribe until something else triggers a "hey, I didn't see that email..." lightbulb.

Also would be great for those who use Project elsewhere for managing projects/issues.

+1 See also http://drupal.org/node/332735 - A destructive Maintainership decision was made in this issue based on "non-responsiveness." Frankly, it took years for me to realize that I wasn't automatically being subscribed to my own projects.

I would *much* rather unsubscribe myself from bothersome projects than be affected by "procedural decisions" that I can be accidentally excluded from.

Another +1, collapsed sections don't stand out enough, I've been wondering why I couldn't get emailled on issue posts for ages.. and greggles just pointed it out, hiding in plain sight!

Major +1

I think this belongs directly in project_issue. In fact, this could be another knob at user/N/notifications once #15380: Allow to configure content of issue notification e-mails is finally tested and deployed. I'm fine with it defaulting to sending you emails on your new projects, but it'd be nice to let people configure the behavior they want automatically on new projects they create. But, as step 0, new projects can start you off subscribed to all issues and you have to opt out (or downgrade to "own issues") for each one. So, the first patch in here could have no UI at all, and we could start from there, then circle back and add a knob about the default whenever #15380 is done.

Since issue subscription code is so ancient and unloved, there's no sane API for manipulating a user's issue subscriptions. So, at this point, you just want to see via hook_nodeapi() when a project node is created, and manually insert a row into {project_subscriptions}. There's already a function specifically for project_issue_nodeapi() when a new project is inserted: project_issue_project_insert(). So, we just need a 2 line patch to that function, a db_query() and a comment. ;)

Patches welcome!

Thanks,
-Derek

Should the comment be expanded with a @TODO about a future UI?

And should their be a note about the magic number 2?
(Taken from $levels = array(0 => t('None'), 1 => t('Own issues'), 2 => t('All issues'));, in project_issue_subscribe_submit().)

I got bit by this again, so bump.

I'm definitely in favor of this. However, I think it'd be better to wait until #397458: Revamp mailing logic to leverage flag module is done and deployed for two reasons:

A) In the scheme of things, that patch is fixing a vastly more important UX bug, so I don't want to create any additional delays for that, force a re-roll, etc.

B) That patch is introducing a user/N/subscriptions page (and DB table) for settings exactly like this. So, once that lands, that'd be the perfect place to make this behavior configurable.

Sadly, I'm just about to leave for ~3.5 weeks offline (with only a day in between to check in on emergencies) so I'm not in a position to drive #397458 home and deploy it right now. However, interested parties should definitely join the party over there, provide reviews, testing, simpletests, feedback, etc.

Thanks!
-Derek

Noted, assigning so I don't lose track once the other patch is in.

p.s. I forgot to mention, but #397458: Revamp mailing logic to leverage flag module also introduces constants for the magic subscription level integers, so that'll be another nice thing for re-rolling this one. ;)

Thanks Tim!

Cheers,
-Derek

Re-rolled for the 34496-flag-integration feature branch. I've already merged #397458: Revamp mailing logic to leverage flag module into this branch, so we can use the new APIs and constants for this stuff. Tested and working fine.

I'm still pondering if we should add a per-user preference to control this behavior. However, I think that should probably wait until #15380: Allow to configure content of issue notification e-mails is re-rolled and merged into the branch, since that's probably going to conflict.

So, we could always just commit this now as-is, and open a follow-up issue about expanding it with a preference.

+1 for this functionality. Often I hear maintainers complain that they had no idea people were filing issues in their modules because they weren't even subscribed. I would be very worried about making this with no opt-out capability though. What happens when a module changes owners? Or project is marked with an abandoned status?

I'd suggest to couple this automation to the user's global default preference for getting e-mail notifications.

If it's "none", then we know that the user does not want to get any e-mail notifications at all (even for newly created projects).

Prerequisite: Having a preference configured in the first place.

Attached patch adds the condition, and outputs a message for all users that haven't configured their preference yet.

I posted an idea on ideascale that expands this a bit: Our problem is that we need an easy way to follow our own issues, issues from colleagues and keep an eye on the issue queue from projects/sandboxes we co-maintain, so it would be nice that we can auto follow all new issues based on projects/sandboxes we select.

attiks: You can already get email notification for all issues from individual projects you care about at the Notifications tab on your user profile page. This issue here is just talking about email notification so that by default you get emails for all issues from projects you create, even issues you're *not* following.

You're either talking about automatically following all issues from specific projects and/or a way to see all issues for a set of projects, not just the ones you own. In that case, you want to see:
#101341-36: 'My projects' should also display projects that are being co-maintained
#1434450: Add the ability to follow projects like we follow issues

Cheers,
-Derek

Derek, you read my mind, thanks for the issue links

http://drupal.org/user/%user/project-issue has a "Default notification" setting, but that is EVERY PROJECT.

What this needs to do is add projects to the individual customizations section when creating them. If we still want to do it.

Also opened #1530038: Allow users to automatically follow all issues created in a project, which is different enough from this (not related to email) that I made it separate.

...sorry to ask this off-topic (though referring to a related issue), but can anybody point to the issue for when a user does not automatically follow issues they file? We do have an issue for that. Right? I searched among the issues I follow and could not locate it any more - might have accidentally un-followed it.

@klonos: No idea what you're talking about. You mean that's a feature request to add the ability not to follow your own issues? Or are you claiming there's a bug that users don't automatically follow their own issues?

Thanks,
-Derek

...this is not the same as the issue I'm having, but searching for a fitting one did not yell any results. Sometimes, when I file a new issue in d.o, I'm not automatically subscribed to that issue and I need to manually press the "follow" button.

...it just happened again. Am I the only one seeing this behavior?

It is okay to go ahead and commit this to 7.x-2.x. On visual inspection, the API looks the same and I'd expect this code won't throw any new errors. A thorough round of work on #1560012: Port per-user issue notification email functionality to D7 will fix up any problems from this new code.

The patch you guys just committed into Git is actually subscribing people to issues, not projects.
I think we should change the following line:
project_issue_notification_project_setting_save($node->uid, $node->nid, PROJECT_ISSUE_NOTIFICATION_ALL);
to:
project_issue_notification_project_setting_save($node->uid, $node->field_project[LANGUAGE_NONE][0]['target_id'], PROJECT_ISSUE_NOTIFICATION_ALL);

Yes, I'm using Drupal 7, did not test on Drupal 6, sorry.

Sorry, I didn't look at the D7 patch here at all. I agree that #26 is a bug. However, the proposed solution in #29 is also wrong. Instead of using hook_node_insert() to find new issue nodes and then try to (re)subscribe the author of that issue to all issues for the corresponding project, we need to be checking for new project nodes, and automatically subscribe the owner of the project node. So, the bug isn't $node->nid vs. $node->field_project[LANGUAGE_NONE][0]['target_id']. The real bug is this:

  if (project_issue_node_type_is_issue($node->type)) {
     ...
  }

Instead, we want this:

  if (project_node_type_is_project($node->type)) {
     ...
  }

That would match what's going on in the D6 version. See what I mean?

Cheers,
-Derek

Not tested, but yeah, that looks right. ;)

Thanks!
-Derek

Tested in Drupal 7, works fine. Thanks guys.