Allow defaults for issue subscription

i haven't thought about this much, but there's nothing obvious to my mind that would be better than what you outline here. so sure, go for it, and see what happens. ;) thanks.

If anyone is still interested in this functionality, you can download our Issue Subscription module which we use on our own system for managing users' project issue subscriptions.

If you are using the Project and Project Issue modules to manage dozens, rather than hundreds or thousands, of projects, this should be useful to you. I hesitate to check this in as a true project on drupal.org since its life span will probably be limited, and it would best be included along with some refactoring of the project_issue code (separating GUI from function), but if there is demand for it, I'll get it in there.

Here's the README.txt:

README.txt - Project issue subscription

This module extends the Project and Project Issue modules by providing:

1. A configuration screen at admin/project/project-issue-subscriptions
that allows users with "administer projects" permissions to set the issue
subscriptions for any user.

2. A configuration screen at admin/project/project-issue-subscription-defaults
that allows users with "administer projects" permissions to set the
default issue subscription settings for new projects that are created. There
is a global setting for all users and all new projects, and then there are
override settings per role. A user who belongs to multiple roles will get
the highest role-based subscription setting for new projects (ie. if a user
is in "Student" and "Crossing Guard" roles and the "Student" role is set to
"My Issues" while the "Crossing Guard" is set to "All Issues" then the user
will be initially subscribed to "All Issues" for any new projects that are
created).

3. An implementation of hook_nodeapi() that carries out the configuration
settings from #2 -- when new Project nodes are created, all users who should
be subscribed to issues will have their subscriptions automatically set. Note
that these subscription settings can be changed at any time via the normal
means provided by the Project Issue module after the new Projects are created.

Sean - I just put the Issue Subscription tar.gz file back up there. Please give it another download attempt.

- Marc

Sean - I'm happy to stay in the loop on this. The 2 additional features that you mentioned sound great, and, yeah, the 2nd one could definitely be dangerous.

I suspect this won't make it into a D5 version of project_issue, so for D5 it may make sense to release the code as a separate contrib module and then work on folding the functionality into project_issue for D6.

What do you think?

- Marc

I'm generally opposed to the subscription functionality in project_issue. ;) That said, I'd be happy to fold in code "upstream" that improves it on three conditions:

1) It doesn't suck (I haven't looked, and have no reason to expect it would).

2) It doesn't assume d.o use-cases (sounds from the description in here it doesn't).

3) It doesn't make it harder to migrate to a better subscription solution in the medium term.

If all of those are true, I'd be happy to look at the code and just commit it upstream. I am a little reluctant to spend much more time on the D5 version since my top priority these days is stabilizing everything for an official 6.x-1.0 release. But, if there's a compelling reason we want this new code for D5 too (and it's ported to both versions), I'd probably just commit it as another sub-module.

Sean - if you compare the code in function issue_subscription_subscriptions_for_user($uid = 0) in issue_subscription/issue_subscription.module and function project_issue_subscribe($project = 0) in project_issue/issue.inc you'll notice that about 50 lines were copied in their entirety with one small change (sending in $uid instead of $user->uid to the project_subscriptions/node/project_projects query).

The function in issue.inc assumes the logged-in user. With a small patch to project_issue/issue.inc to also take in $uid (defaulting to 0, which would leave it functionally intact for project_issue), we'd be able to eliminate about 20% of the code in issue_subscription.module.

I'm all in favor of patches like that.

Sean - sounds good - I've been meaning to put that patch together anyway. Might be a couple days before I get to it so ping me next week if it's not in yet.

Attached is a patch to 6.x that pulls out the global subscription portion of the issue subscription form so it can be reused.

The 6.x version of issue_subscription can be downloaded here:

http://www.funnymonkey.com/downloads/issue_subscription/issue_subscripti...

It operates the same way as the 5.x version, only this one is smaller since it can reuse a good deal of code in issue.inc. The README.txt from comment #3 above is still the same.

Is this patch relevant anymore? In trying to implement I noticed that the code that is supposed to be in issue.inc is not is include/subscription.inc Can someone let me know if that has been superseeded...if not how about an update to the patch for 6.x?

Yikes, that patch is over 9 months old! I haven't looked at the 6.x project_issue stuff lately, but it sounds like the patch doesn't apply any more. The features provided by issue_subscription are useful, though, so it would be worth re-rolling this. I doubt I'll have time in the near future, though, so hopefully someone else will chime in here.

Unsurprisingly, this no longer applies. ;)

That said, my comment #8 above still holds... ;)

Note, fixing this was a side effect of writing the patch over at #397458: Revamp mailing logic to leverage flag module. So, this is going to go live in the nearish future.

Now merged back into the mainline 'master' branch of project_issue and deployed on d.o: Stop subscribing, start following