Add Flag integration

project.module emails all participants in an issue already. just say something brilliant and you are in the email loop ... eventually, this outght to be in subscriptions.module and the follow-ups should be comments

I'd like this feature. Ideally solved with subscriptions, but throwing it in project.module is fine too.

• moving to right queue
• bumping since chx submitted http://drupal.org/node/87479 which is duplicate:
  
  Currently I am auto subbed to any issue I follow up and there is no other to sub and there is absolutely no way to unsub. This is plain horrible.
  
• adding the new thing from chx's followup to #87479:

  
  While we are at it, I am dreaming of more. I would be happy if I would have a 'patch' queue, a 'review' and a 'document' queue.

  So the issue will display like:

  Likely to be coded by: chx, eaton
  Likely to be reviewed by: webchick
  Likely to be documented by: sepeck
  

Subscribe *grin*

+1 though

Now I'm subscribed too. ;) +1 for this request.

I would also like to see a user profile entry to set the default subscription method for new projects added.

subscribe

there's no question this is worth doing or not, so there's no need to "vote" in favor of the request. all you can do to help this issue is a) write the code, b) hire me or someone else to write it, or c) wait until this becomes my top priority and i implement it myself. a large pile of "yes please! +1" follow-ups in here will only make this issue long and more confusing/time-consuming to read. thanks.

duplicate post

Since the more general request for an "add to tracker" was dup'd for this one, I need to ask: What about forum posts? I'd like to see some sort of subscription for those as well. I get tired of ancient posts getting bumped up because people don't want to bookmark them in their browser. Since Dries has already come out against adding a bookmark feature to d.o, being able to add them to your tracker would be nice.

Thanks,

Michelle

@Michelle: Now that issue followups are comments (IFAC), any solution to this problem will be a more generic one that would work for anything that currently allows "subscription" via adding a comment.

dww - That's what I was thinking, but the title specifically says "project" so I wanted to be sure it would work with the forums, too.

Thanks for clarifying,

Michelle

We've been using the Google issue tracker for the G-HOP stuff, and it actually has a pretty nice subscription interface for this, which I think we could do even better. Mock is attached.

Then the query in My Issues just goes against the {project_subscriptions} table or whatever instead.

Actually, I like the idea of checkboxes even better.

This would be really nice to have, but I wouldn't call it critical.

subscribe

I think this is quite an important issue.

I concur with Michelle about there having to be better subscriptions for forums. I run a site with vBulletin and if it wasn't for subscriptions our website wouldn't even be half as busy.

Although I'm not sure I could code a decent subscriptions module myself, it's not breakthrough science so if anyone did have the knowhow to improve on it, you'd be helping thousands of people!

In my opinion, I think that subscriptions almost as important as RSS and nodes themselves, and functionality should be included in core.

@chrism2671 There already is a subscriptions module. What's needed is to get the bugs shook out and get it stable enough to be of use. I'm guilty of not helping there because I just uninstall it when the current beta crashes my site. :( I need to get on the ball and start filing issues and patches where I can. But that's something you can help out with as well.

Michelle

FWIW, I think the Notifications framework is more modular and will be better maintained. Thats where m y integration efforts are headed for OG module.

@chrism2671: While I agree with your comments, they are mostly off topic for this particular issue. This issue is specifically about subscriptions to issue node types. However, depending on how we solve this problem, the solution may also be useful for other content types (for example if we use the subscriptions module on d.o, we could configure it to provide subscription emails for forum postings also).

I haven't personally used either the Subscriptions module nor the Notifications framework, but it doesn't look like either of them have a true stable release (one is alpha, one beta), and it doesn't look like either of them has made much or any progress towards a Drupal 6 port.

I believe that changes in subscriptions, with respect to project issues, will probably come after a D6 port of project*, unless someone comes in before then and works with us to make it happen sooner. Hopefully the D6 port won't be that far away since I do agree that it would be nice to improve our subscription functionality.

As Michelle mentioned, I'd like the option to add to tracker as I don't want to receive emails about issues beside security issues so I often consult my tracker but I get annoyed at issues which are too popular and I simply start to ignore them, I would like for those that there would be an update option to only notice on thread reply and no notice so I wouldn't even have to look at the update notice in the first place saving me the hassle of deciding if I'll ignore it.

subscribe - oh the irony. :-)

Obviously this'd be a great thing to have. I tend to use 'my issues', and not rss feeds much, so it'd be good to have my issues recognise subscription information. Additionally I'd also quite like to have the option to unsubscribe from issues, even if I've posted on them - although that might be less of an issue when people don't have to post subscribe messages any more...

So a developer spammed the entire planet with a rant about this the other week, with tons of "YEAH! It bugs me too!" in the comments. I suggested that anyone interested in fixing this problem come here and help, and of course no one did. Whatever. :P~

Anyway, I happened to have a plane ride yesterday that was too noisy for book chapter reviews, so I sat down to evaluate Notifications vs. Subscriptions vs. Project issue mail.inc, since that's probably the primary thing holding this up -- what solution to go with? I got hung up on some Drupal.org testing profile issues, so I didn't get quite as far along as I'd like, but I wrote up my findings on the Issue tracking group: http://groups.drupal.org/node/12645

Subscribing to this 3 years old thread.

LOL, this is the ultimate thread to subscribe to!

I think the flag module accomplishes this task. The views integration adds the desired functionality.

You create the flag (subscriptions), choose node types that are flaggable (issues, etc), and add "flag:ops 'flag_name'" field to the views output on project/issues/ (subscribe/unsubscribe to this issue).

mitchell: Yeah, that would work great for building a list of "my issues" and also for providing a feed for this information.

But something it won't help with is e-mail notifications. :( There's an extensive e-mail subscription interface available at http://drupal.org/project/issues/subscribe-mail. Unless there's a "Updated View 2 E-mail" module out there that I don't know about?

But something it won't help with is e-mail notifications. :( There's an extensive e-mail subscription interface available at http://drupal.org/project/issues/subscribe-mail.

And that interface is lacking a user preference for new projects added. So every few months you need to try to remember to revisit that page and reset the own issues so that if you happen to create an issue you receive email.

@earnie: That's a separate issue. #144308: Allow defaults for issue subscription.

subscribe

+1 oh, I am so evil.. :)

There are too many half alternatives available. Yet not one of them can get the entire job done. This topic is certainly gaining momentum lately so I hope we can reach a resolution for D7.x

webchick: Your mockups are very feasible now. The original post is best answered with a combination of these modules in D6: Token (includes token_actions.module has token_actions_send_email_action), Trigger, Views, and Flag.

moshe: Using drupal's actions system seems like the best system for sending emails. Here's a comparison of the sizes of each project that has been offered as a solution:

Subscriptions: 100KB
Notifications: 50KB + Messaging (dependency): 30KB
Flag: 30KB

Quicksketch provides a good explanation of Flag's usefulness in the issue of changing the name from Views Bookmarks to Flag.

agreed. flag is quite cool. i'm happy to use it here.

If we have flag, then presumably we could add another flag to unsubscribe from an issue? The first page of 'my issues' is rarely more than 24 hours old, and if it's something which I just moved to the right project a year ago that's been bumped with 'subscribe' messages for 6 months then I'd like to be able to kill it from 'my issues' and just have it show up in /tracker/uid which I rarely look at anyway.

So the logic would be something like ($posted || $commented || $subscribed) && !$unsubscribed

Flag is a simple on/off toggle, all AJAX-like. So the opposite of subscribed would be unsubscribed. :)

Oh. I see what you're saying.

I would approach it slightly differently... use Flag's actions integration to automatically toggle the "Subscribe" flag upon post or comment. then you could go back and untoggle it manually if you wanted.

Definitely we want this, and yeah, I was imagining it'd be like webchick describes: you automatically subscribe if you create or reply, but you can always unsub even if you reply or create. If flag is the way to go, then we either need:

A) Blessings from Dries/Killes to run it on d.o.

B) To hurry up already with (project|downloads|whatever).d.o so we can decide what modules we want to use on our own.

(A) seems like the shortest path at this point. Anyone want to send those folks a message with a pointer to this issue?

p.s. a non-beta official 1.0 release of flag would be nice, too. ;) Any word from quicksketch on when that's coming?

Also, do the flag folks think flag can scale to the size of d.o's issue queues? We're talking 131458 issues with 562372 comments on d.o right now. Total # of users == 345630. I'm not claiming project_issue scales perfectly, but at least it's a known evil. ;)

If we go with the actions integration in #37 (which I agree sounds lovely) - are we going to have a bulk update to subscribe everyone to all their issues that they're already subscribed to via posted/commented? I'd hate to go through (...looks...) 16 pages of issues just to work out which ones I still want or not.

The backwards-compatibility stuff could be taken care of in an update hook, yep.

Derek, is this functionality you're interested in "outsourcing" to Flag module in Project module as a whole (as OG now does its e-mail notifications through Notifications module?), or is it something that'd be more appropriate in doing in drupal.org module?

I've no idea about the module's scalability or a timeline on the 1.0 release. I'll ping quicksketch and see if he has thoughts on the matter.

Yup -- any solution that moves project_issue to depend on flag will have to have an upgrade path to support existing data in sites such as this one. ;)

Although I've never looked at the code or used flag, I'm definitely interested in "outsourcing" this to flag generally for project*, not just as a d.o-specific hack. Given who wrote it and what people are saying, it seems like the obvious candidate for this task. One of my long-term goals with project* is to replace any parts of it that are handled better by other modules.

Other thoughts:

A) How fill flag interact with email subscriptions? It seems like the primary thing we're talking about here is the "My issues" view, but email subs are also important. We need to figure out what we're doing about email subs generally -- probably we should also just require notification or something. I guess that discussion belongs over at #231414: Create a pi subscriptions roadmap and/or the g.d.o wiki that issue proposes.

B) [Related to (A)] How will flag handle the issue email subscription stuff for all issues for projects I care about? E.g. if you subscribe to all issues for project foo, how will flag know about that and auto-subscribe you to all issues that are created (or reassigned) to the foo issue queue?

I checked out the dev version of flag on my D6 test site, and since project issue hasn't been ported yet I added a flag to project nodes instead, just to check it out. It looks pretty slick and I think it would be a good choice for us to go with. As is it uses a text link for subscribe/unsubscribe, but it looks like it should be pretty easy to theme this into a small image (perhaps a star or mail icon or something, I think this has been discussed some elsewhere) instead of a text link.

One thing I touched on in my comparison of project issue to the Google Code issue tracker was that in Google's tracker, you can star an issue, and doing so means that you'll get email notifications when new comments are added (assuming you've checked the box on your settings page to get email on issues you've stared). By default, issues you create are starred as well. There's a separate setting to always receive emails if you are the issue's owner or in the cc field of the issue. Issue owners are not necessarily the person who created the issue, however--owner is just another field like assigned, etc. There's a cc field that users can add people to when commenting on an issue. These two things wouldn't translate terribly well into our issue tracker.

Here's how I see this working for us. Every issue you create or comment on is by default also starred by you. By default, you always get an email for issues that are starred. You can of course unstar issues, or star issues you have not commented on. But you'll only get email notifications for issues you've starred (assuming you check a new "send me an email for starred issues" setting somewhere). Or, better yet, we keep the current subscriptions interface (at first, at least) and just change the "my issues" option to read something like "my starred issues". That way we can also keep the "all issues" subscription option and the db update is simpler.

For the "my issues" page, since we'll be using views for this, we can make this a lot more useful. We could write an exposed filter handler that provides several options, similar to the select box next to "Search" at the top of http://code.google.com/p/google-highly-open-participation-drupal/issues/...

For example, view my starred issues, view issues assigned to me, view issues reported by me. In reality, I think we might end up using a single view for all advanced search, and the "My issues" link would just point to the path of this view and by default have the exposed filter mentioned above set to "my starred issues" and the projects select box set to "all projects".

So the database update would need to flag all issues for each user that the user created or commented on, but only if the user has checked "own issues" in the subscriptions interface for that project. This might be a bit tricky, but I think it's better than trying to add flags to "all issues" in particular projects, etc. Then, the code that sends out the emails will send an email if one or more of the following is true:
1. The user has subscribed to "all issues" for the project
2. The user has flagged the issue and has subscribed to "all flagged issues" for the project.

It might just be that I haven't had breakfast yet, but this all seems relatively simple to me and would greatly enhance functionality. So what am I missing? :)

If someone wants to do the update, thats great. But personally, I would be fine with wiping the slate clean and telling people to star old issues if they care about them. Glad to see flag module solution progressing. I agree it is solid.

If it makes it easier, then I could probably live without the update too - since old issues will still be bumped in the tracker.

@aclight - I think I agree with Moshe: keep the existing view/page to ?q=project/issues/user then add another page (or an arg to the main page?) to just showed starred issues. Since newly created or commented issues will get starred, I think it's fine if there is a transition period where users should star older issue that they care about and want to see in the new view. That we we could absolutely minimize the update code. At some point, we could switch the "My issues" link to point to the new page.

Granted, some sites using project* might want a different update path, but they should be able to figure it out.

I would not support a change that did not have an update path. We are trying to write project* with other sites in mind other than d.o, and not providing an upgrade path for this important functionality would be a mistake, IMHO. For people that don't use email to keep track of issues it might not be too big of a deal, but for those of us who use email it would be a major loss in functionality, both for d.o and for sites using project* outside of d.o.

My preferred long-term solution to mailing issues is the (mythical, not yet coded by anyone, afaik) "Views Mail" module, which will e-mail a given user whenever a node within a view is added, updated, or commented on.

This would have broad applicability far outside of simply Project issue module, which would make it a great place for contributors to swarm.

Also, I would prefer to keep the e-mail options and "My issues" functionality separate, if at all possible. I get more than enough e-mail as it is, I hate that e-mail and web read statuses are out of sync (I've read something on d.o, but it shows as unread in Thunderbird), and the web interface is quick and easy for me, since I'm on d.o 80 hours a day anyway. :D

However, I'm comfortable going with whatever the easiest approach upgrade-wise is, and then submitting follow-up patches or whatever's needed to get it to stop spamming my inbox. ;)

I didn't intend to suggest that email notification would be mandatory. My suggestion was that email subscriptions wouldn't change from what they are right now, except that instead of subscribing to "own issues" you'd subscribe to "my starred issues" and issues you created or commented on would be automatically starred (and you could unstar them, of course). So if you're currently subscribed to no issues in a project or projects, you would continue to *not* get email for issues on those projects.

Re: #50 -- yes, that sounds right. Basically, this issue is about redefining "own" issues in most of the UI from "everything I created or commented on", to "whatever I care about" with the default behavior that you care about things you created or comment on, but not as an IFF requirement. I hope that makes sense. ;)

Places that will see this change in "own" behavior include the "My issues" page and the behavior of "own issues" email subscription. Places that will not be changed by this include the meaning of "own issues" for the purposes of ACLs. ;) There might be other areas that have a notion of "own issues" that we'll come upon, and when we do, we just need to decide which definition makes the most sense on a case-by-case basis, ideally, being as consistent as possible.

I think that aclight's proposal make alot of sense and seems to be flexible enough as well.

FWIW, unfuddle has a very userfriendly approach to subscriptions. They do not handle the "send me updates about this thread", but rather the general update-mailing settings.

See screenshots for the interface.
I especially like the way the digests are broken up. And I find the [x] However, don't .... setting at the bottom extremely usefull and clear.

A suggestion:

In the comment template on Drupal.org, do not display any comment which says just "subscribe" or "subscribing".

This would halve many issue comment lists today, and provide a clean solution while we wait on implementation via flag or other more complicated methods.

I can't see that any discussions would be harmed by this approach, apart from possibly dropping the irony level in this years-old thread by about 15˚ ...

do not display any comment which says just "subscribe" or "subscribing"

that does not help, because that's not the problem..

the problem is that these threads are marked as "updated", when there is nothing to see..

@webchick: #37 has been approached! check out Rules integration with flag!

Flag already stores how many times an object (node) has been flagged. Flag will also allow novel approaches for Patch Spotlight 3.0. Definitely the way to go.

Effectively, attached patch adds optional support for Flag module. If Flag is available, the "My issues" list is based on a user's starred issues (instead of whether she participated). However, we still need the 'participated' query argument to allow to search for issues.

Please let me know whether there are objections to the direction of this patch. Of course, it's only the ground-work. However, "My issues" are properly filtered by starred issues already.

Opened #330141: Allow modules to expose default flags for further consideration. If that one will not be fixed when we need it, we can simply go with a configurable variable in project_issue, since the current state of this patch needs to manually check for potential flags to use. Attached is also the flag configuration I used.

Note that $_GET['participated'] is not used throughout issue.inc, thus removed.

subscribing.

Subscribing.

Please do not derail this issue by just adding "subscribe" to this issue. The less "subscribers" the less derailment the earlier it will be done.

To move this forward, I need substantial and unbiased reviews. Either you know how to read code and how this patch affects project_issue, or you have to install the Drupal.org Testing install profile and apply the patch.

Thank you.

@sun: Unfortunately, posting a comment with "subscribe" is the sanctioned way to subscribe to an issue on d.o at the moment. It's not ideal, but it's the only option.

It's not clear to me, but it seems that your patch must be against the Drupal 5 version of project issue (since there is no version of pi for D6), yet the version of this issue is set to 6.x. I suspect that we're going to want to hold off on adding a new feature like this until we release a D6 version that uses views.

As I said in #43, 47, and 50 above, I don't think that we should change the behavior of the my issues list, which seems to be what your patch would do. Instead, we'd want a new "my flagged issues" list or similar. To have that, we'd then probably want to use Views to create that list, but the views integration in the 5.x version of project issue is spotty.

Ultimately, I think this needs to be tackled after we have a working port of project issue for D6. Personally, this will be one of the first things I do once we do have a D6 version, because I'd also love to see this feature.

"sanctioned" is a strong word. It's more, "this is what people do and if you don't like it that's tough because people are going to keep doing it until there's a way to subscribe to issues."

Hopefully this issue will fix that. And, yes, I'm fully aware that I've done nothing to help but the fact is that it is impossible to help out in every single area of Drupal that you have an interest in seeing something done so, yes, I do at times complain about things that I am not helping to fix.

Michelle

Hm. The patch is against HEAD, which still seems to be compatible to 5.x. Absolutely unsure whether that's 5.x-1.x or 5.x-2.x.

Well, let me explain. My intention with this patch is to have it on drupal.org. If drupal.org was using Views already, all of this would be easier, since we would have to conditionally alter pi's issue mail subscription feature only. But d.o is not using Views. I know that p's and pi's ports to D6 are on their way in parallel. However, although there is (or has been?) some progress, it is very vague when drupal.org will be upgraded to 6.x, also given the fact that an upgrade might already incorporate further changes due to the d.o redesign.

Hence my reasoning: We can implement Flag integration in the currently used version of pi without major changes to the module, and without affecting existing sites using this version of pi. The good news is that when pi will be upgraded to 6.x, most of the integration code is no longer necessary (due to Views). Additionally, Flag is already available for 6.x, and since the maintainers of Flag ensure compatibility between both branches, upgrading Flag to 6.x is simply done by replacing the module. Of course, the bad news (for me) is that this code and effort has a limited lifetime and will not be used any longer after upgrading to 6.x.

There is a broad agreement throughout the community (including Dries, according to his latest statement on devel list) that we badly need this functionality as soon as possible. That's why I would love to deliver it. I hope my explanation above sufficiently described that implementing support for Flag would not affect the speed or process of other ongoing efforts at all. Even if it would be considered as overhead during the upgrade, I see no problem if pi reverts to its default method and users will be temporarily notified for all issues they participated in - until support for Flag has been re-implemented in pi (or Notifications?) in 6.x.

Lastly, after tinkering further about this optional integration, I agree with you that "My starred issues" should be on a separate page.

FYI, HEAD and DRUPAL-5--2 are the same right now. I changed the version of this issue to 5.x-2.x, since the 5.x-1.x branch is no longer supported. I'm still not sure that this issue actually belongs in the 5.x branch at all, but we can keep it here for now.

My opinion is that if we're adding functionality that's specific to d.o, it needs to go in the drupal.org customizations module. If it goes in the project issue module, then I think other users of the module would legitimately expect that the feature is supported, at least to some extent.

As I said before, I feel that any integration with the flag module should provide additional functionality, and not change existing functionality. So, we'd have a separate page for "my flagged issues", but project/issues/users would stay the same as it is now. In addition, our email subscription feature would stay just as it is now. Assuming this all is true, then I don't think the project_issue module itself would need any code changes, but d.o could run the flag module and provide the ability to flag issues. We'd need to enable the Views module to provide the view of "my starred issues". Furthermore, there would probably be no email functionality, which would be a bummer for people that follow issue queues exclusively via email.

I think implementing this without modifications to the project or project issue modules is the best way to go, for now at least. Any time dww, hunmonk, or I spend reviewing patches or working on code for this feature is time we're not spending on the D6 port. It's great that you've worked on a patch for this issue, but ultimately I think we'll be better off in the long run if we don't attempt to keep applying band aid solutions to the modules. Otherwise, they'll never get ported :)

Flag will not handle the email portion of this, but would definitely be a great solution once it is integrated with Messaging/Notifications:
#312259: Investigate subscription / notification solutions

However I'm not sure this feature will be worked on until we take care of this one:
#330141: Allow modules to expose default flags

subscribe - I love these old threads :-)

subscribing

Will take a look at this to see if we can get it in 6.x-1.x for the d.org upgrade.

subscribing

guessing this needs to be bumped to the latest version.

Bleh to this, but yeah, subscribing in earnest.

I agree that there should be a way to subscribe to issues without commenting. It'd be nice to simplify the comment list by not seeing a bunch of comments that just say 'subscribing, thanks'.

This patch is no longer needed. All of the functions it's touching don't existing in 6.x-1.x-dev anymore. ;) To actually roll this out on d.o, we need:

A) To get killes to agree to let me install this module. David Strauss and I are sitting in a hotel lobby right now reviewing the code, with quicksketch (flag maintainer) to talk through any issues. So, assuming everything continues to go well, we just need killes to sign off on it, too.

B) We need to make tracker2 know about flag module in some way, because it'd be confusing and weird if "My posts" and "My issues" behaved differently.

C) We need to write an action for sending email to everyone who flagged an issue node, the entire issue queue, or site-wide.

D) To modify the default "My issues" view to honor flag if it exists instead of its current behavior.

I'm working on A and B with David now. hunmonk is going to work on C, perhaps latter tonight. I'll work on D when there's more progress on the other tasks.

Awesome.

One thing that might be worth already taking into account is: We should not only allow to flag issues, but also entire projects. That would allow contributors (and co-maintainers) to have a list similar to "My projects" ("My starred projects" ?), track them, and help out where they can. The effect would be a "My projects"-clone, but without changes to e-mail notification (handled elsewhere).

Not necessarily part of the first implementation, but something that would be good to bear in mind.

Great... I would love to see a tab like "My co-maintained projects" or better a user setting that allows me to enable other projects to show in "My projects", but not all I'm co-maintaining.

"B) We need to make tracker2 know about flag module in some way, because it'd be confusing and weird if "My posts" and "My issues" behaved differently."

Really? I would expect tracker to behave as tracker currently does: anything that I created or commented on shows up there.

I would expect "my issues" to be only the issues I deemed important enough to subscribe to, regardless if I created or commented on them or not.

Same here. I don't want to have to flag every item that goes into tracker. While the unflag ability would be nice on rare occasions when I'm tired of a thread, gaining that isn't worth it to have to manually flag everything I touch.

Michelle

Or to put it in simplicity: Automatically flag an issue when submitting a comment. Afterwards, retroactively flag issues a user has commented on. And replace "My issues" with all flagged issues of a user. Best of all worlds.

What sun/#79 said. :)

/raises hand to work on - point me at it and let me go!

Oh, auto flagging? That would be perfect!

Michelle

@all: Auto-flagging while commenting is absolutely the idea. I guess I forgot to include that in the summary of tasks in #74. The problem with leaving tracker alone is that for people who rely on "My posts", if you need to comment for it to show-up there, people will still "+1 subscribe" in issues. We need to ensure all "my" trackers use the same system or there will be confusion and the problem will remain.

So, we just need:

E) A checkbox on the comment form "Flag this post" which defaults to true. Not sure where's the best place for this code. Ideally in flag itself somewhere. If not, perhaps a simple "comment_flag" module or something. Dunno.

@sirkitree: Thanks for the offer. At this point, most tasks are either blocked on killes or David. hunmonk said he was going to work on (C), but if he hasn't, that might be a good subtask to split out. Just check with him in IRC and find out the status. Or, you could look into (E) and figure out if something like this already exists somewhere, and if not, find out the best place to put it and write it.

Thanks!
-Derek

p.s. We also want (E) on node forms. Authors of nodes should flag those nodes by default.

In reference to (E): I'm not so sure that we should need a checkbox on new comment submissions. Flag already provides a flag link (which in this case would be upon the parent node) and we can display this on every comment if need be. It would simply say 'subscribe' or 'subscribe to this issue'.

If we want to auto-subscribe/flag upon a comment, well there is actions integration which can handle that. The user would be subscribed by default and if they wanted to change this, then any and every link that used to say 'subscribe' would now say 'unsubscribe' and a user can hit that.

Is this an unacceptable workflow?

As for (C) I'll try to get hunmonk's attention.

#85 sounds reasonable to me. I don't think a checkbox is needed.

Michelle

Yeah, (Flag) Actions is the way to go. 1 per-user flag "subscription" (Subscribe/Unsubscribe) that applies to all content-types on drupal.org. "My issues" lists all flagged project_issue nodes, Tracker lists all nodes, regardless of type (minus issues?).

That way, we can subscribe to issues, handbook pages, forum posts, stories (news), etc.

If we want to auto-subscribe/flag upon a comment, well there is actions integration which can handle that.

Maybe I'm missing it in the UI, but I don't see how (I've got the latest from DRUPAL-6--1 on a test site with core trigger.module enabled). There are flag actions to trigger "real" actions once an object is flagged a given number of times. E.g. you can use flag_actions to automatically unpublish nodes that are flagged "inappropriate" 3 times or something. However, I see no generic action for "make the current user flag this object" that we could trigger from "After saving a new post" and "After saving a new comment". Can someone actually explain/show how to do this using the current flag + flag_actions code? It's actually more complicated than this, since the action we'd need to assign to the "After saving a new comment" trigger would have to be "have the current user flag the node this comment belongs to"...

Anyway, I don't care if the UI is a checkbox while creating new content or we just rely on the "unsubscribe" link after they post (since it's going to be rare, anyway). But, it still seems like we need to write some code for this (perhaps adding a feature to flag.module itself to support this). Someone please explain to me exactly how and why I'm wrong about this. ;) Thanks!

Sorry, I didn't explain far enough. I was thinking this would be part of (C). Part of that would be writing an configurable action to execute a given flag and then we can add that to a Trigger and submit it as a feature request to Flag module. Does this sound acceptable?

So, appending to (C):

C) i. We need to write an action for sending email to everyone who flagged an issue node, the entire issue queue, or site-wide.
ii. We need to write a configurable action for executing a given flag so that it can be added to the Trigger: After saving a new comment.

I can work on these tonight. Still haven't caught up with hunmonk yet to see where he is at, but I can work on C.ii

I'd just keep (E) separate. Even if (E) and (C) are both features we want to add to flag, they should be in separate issues, since they're basically completely different features (think of the kittens). So, the very next step is submitting those two issues and posting the links here. Thanks!

created #397464: Action for executing a flag and #397458: Revamp mailing logic to leverage flag module

Please see Nate's update... thoughts? #397458: Revamp mailing logic to leverage flag module

it looks like we have the logic down for creating flags on new node/comment submission over at #397464: Action for executing a flag

there's a couple of loose ends to tie up for the global subscribe options we currently implement:

1. Subscribing to an entire project: currently we give the user the option to subscribe to all issues for a project, which i'm assuming will be replicated by adding a 'Subscribe to all issues' flag on project nodes. i see that being used in the workflow in one of two ways:
• each time a new issue is created for the project, it is auto-flagged with all users who have subscribed to the project itself
• the flag is examined in addition to per-issue flags in any actions we take -- ie, "send emails to everyone who flagged the issue AND everyone who flagged the project"

i'm not really sure which approach is better. thoughts?

2. we have the same issue as in #1 with the "all projects" option we have currently, which allows users to subscribe to all issues from all projects. i'm actually kind of wondering if we really need this functionality -- on sites with only a few projects, it wouldn't be that hard to manually subscribe to new ones as they came along, and only a crazy person would subscribe to all issues on all projects on drupal.org ;) there's also the project/issues RSS feed...

also, i'm wondering if we're tying the email functionality too closely to the idea of subscribing to an issue. what if somebody wants to use the subscription functionality but not get emails? i think i might like to just use an RSS reader myself :) i'm not sure how we would handle this in the UI, but it seems like something we should at least consider as we're moving to a new subscription model...

what if somebody wants to use the subscription functionality but not get emails?

That's me! I don't even have emails turned on for my own queues. I much prefer using the website for issues and I'd like to see something similar to the "my projects" page for issues I have subscribed to.

Michelle

we have the same issue as in #1 with the "all projects" option we have currently, which allows users to subscribe to all issues from all projects. i'm actually kind of wondering if we really need this functionality -- on sites with only a few projects, it wouldn't be that hard to manually subscribe to new ones as they came along, and only a crazy person would subscribe to all issues on all projects on drupal.org ;) there's also the project/issues RSS feed...

I think we should continue to provide the ability to subscribe to all issues of all projects, as well as "my issues" of all projects. The later is especially useful, though I think the former is also quite useful in a lot of cases. One problem with the current implementation of these is that as new projects come along they are not included in the "all projects" or "my issues of all projects" unless a user edits his subscriptions and then includes new projects that have come along since the last time the settings were edited. That's a pretty annoying problem (and I know it has an issue of its own). For example, on d.o, I would like to be able to subscribe to my issues of all projects but don't want to have to periodically redo this as new projects are added.

For your first question, I think the second option makes more sense. Otherwise, going from subscribing to all issues in a project to, for example, only "my issues" would unset any flags the user had specifically set on issues that might interest them.

Regarding email functionality, I'd say that, at least until we build something like support for the subscription or notifications module into project_issue, we could just have a per-user setting for whether emails should be sent to issues the user has flagged. If this gets done, can really should also add a setting for whether all previous comments in an issue should be included in that email #219751: Add a master subscription setting to receive all issue email notifications, so that we can actually fix #15380: Format issue mails as proper digests.

93.1.B) is definitely the way to go. It's easier to code and vastly more efficient in terms of how much data we have to store.

93.2) We definitely just want a global setting per-user, not any auto-flagging stuff. And, we definitely want this setting. Remember the security.d.o use-case: it's still a ton of projects, but we want security@d.o to be subscribed to all of them.

I thought we were pretty clear about this when we spoke in DC. We want 3 levels of granularity (site-wide setting, per-project flags, per-issue flags) and the logic when deciding who to generate emails for checks all 3. Otherwise, we just perpetuate the evil design of the current system and all of its problems, include wasteful storage and the fact that new projects/issues miss out from the higher levels of granularity.

Re: email -- I like aclight's idea of a per-user setting that says "send me emails for issues I'm tracking" or however we word it. And, I like the idea about adding some options to control the nature of those emails. While we're at it, we could move the issue status filter stuff out of the project nodes into this per-user setting, which would be nice (so you could still track all issues via the site, but only get emails for the ones in the states you care about, etc).

We should definitely remember this weird "other" subscription functionality as we work on this. Maybe we should just remove it entirely. It seems weird for the project itself to be able to "subscribe" via email to issues in this way -- that should really just be up to each user. OTOH, it's nice for things like the infra and webmaster issue queues to have those mailing lists auto-subscribed. Or, maybe not. ;)

Boil down summary of current status:

• There is a difference between flagging/tracking issues and subscribing to issues.
• Currently, we allow users to track an issue by creating it or commenting on it.
• Currently, we allow users
  • to subscribe to no issues or all issues of a project.
  • to subscribe to tracked (own) issues of a project.
  • to subscribe to all issues of all projects.
• Currently, we allow maintainers
  • to track all issues in their projects ("My projects").
  • to subscribe to all or certain issues of their projects. (note that, when enabled, maintainers may receive duplicate mails depending on their regular issue subscription settings for a project)

Originally, I thought we would just add a new way for tracking additional issues without subscribing to them. Now we advanced to even more awesomeness. Because of that, I think we need some crystal clear refinement of what we want. Let me try:

• There is a difference between flagging/tracking issues and subscribing to issues.
• Users track (flag) an issue by creating it or commenting on it, which makes it appear in "My issues".
• Users can flag an issue without commenting on it (no more "+1 subscribe").
• Users can unflag an issue to remove it from their tracker ("My issues").
• Users can
  • subscribe to no issues or all issues of a project.
  • subscribe to flagged issues of a project.
  • subscribe to all issues of all projects.
• When users are subscribed to all issues of a project, they can select/filter their subscription to certain issues.
• Users (once maintainers) can
  • flag projects to track all issues in them ("My projects").

So, if we want to replace the entire issue e-mail subscription logic, that would equal the tasks:

1. Replace the "own issues" logic for new issues and commented issues by auto-flagging an issue when creating it or commenting on it. (Note that this does not work retroactively like the current system, but you can still search for issues with certain participants.)
2. Add a link to the issue node (page) view to flag/unflag the issue.
3. Per-project subscription settings page to subscribe to no issues or all issues of a project is still required.
4. Replace subscribing to "own issues" with "flagged issues".
5. Move the issue selection/filter (once maintainers only) to the per-project subscription settings page (http://drupal.org/project/issues/subscribe-mail/image) and (conditionally?) display/enable it for "all issues".
6. Phase 2: Allow users to flag projects and replace "My projects" logic to _track_ all issues of all flagged projects (subscriptions handled elsewhere).

In short: We keep the current issue subscription settings, but replace the entire logic for subscribing to "own issues" with flagged issues.

Hope this helps.

One thing that would be lost for a project maintainers/other participants is a gauge for the interest of each issue in the tracker. You can currently see approximately what issue has the greatest interest by all the "subscribe" comments. If we lose those, we lose an idea of the amount of interest from the community.

I think this can be resolved...
By creating a page for each project that lists the issues according to their subscription/flagged count, we can remove the loss of this feature and even strengthen its usefulness. The greater the number of subscribers the higher in the stack it would float. This would help gauge community interest and prioritization of time/investment.

@flickerfly: Seriously? As a maintainer, I find subscribe comments incredibly annoying and can't wait to loose them. I don't need 20 people piling on to tell me that they really want me to fix some problem. That's one of the reason I'm looking forward to this. LOL!

I think if maintainers need feedback on an issue, just saying "leave a note if you would like this" would work.

Michelle

Of course, the amount of flags an issue has is the new measure for popularity of a feature request or ugliness of a bug. I assume that we want to replace the comment count in the tracker views, or, add a new column for the flag count. However, let's leave this particular question for later.

@Michelle, totally agree that subscribe comments are akin to evil, but they do provide a small bit of information that could be automated and not require any sort of special request. I think commenters wouldn't be as quick to add further useless info if subscribing also meant adding a vote. That's the "+1" part of those comments and they won't be chased of by anything that neglects that desire to express interest. Besides, the automated measure would seem to be more accurate and never require clutter of any kind in the middle of a discussion.

@sun, I don't think you'd want to remove the comment count. That is telling something else, community activity (not community popularity). I suppose the difference is rather subtle, but adding it as a new column would then add clutter that I don't think is needed. As long as this is in the discussion as "to be conscious of", I'm comfortable leaving it to a UI decision later. BTW, thanks for the great compilation of all that other stuff.

As a maintainer, I loathe +1 "comments" even more than I loathe "subscribe" comments. IMO, if people want to see a patch go in, then they should be *participating* in the issue: reviewing the code, testing it and reporting results, etc. Casting votes does absolutely nothing to forward the cause.

Or to put it in simplicity: The flag count is our new way to "confirm" an issue. We want comments to contain actually useful data for maintainers and contributors. Both counts/indicators are useful.

Somewhat related to #171350: Reorganise project issue statuses :)

myself, hunmonk, webchick and Crell had a very productive discussion in IRC to clear up a few things about all this. I'm going to attempt to summarize. The biggest fundamental problem was how to handle the e-mail aspect of all this. Here's our current working proposal:

A) There's only 1 flag on issue nodes (and forum posts) for "subscribe/unsubscribe". We don't need separate flags for "track" and "email me this" after all. Phew.

B) #397464: Action for executing a flag -- This needs someone to work on it -- quicksketch is willing to have the code live in flag.module, but doesn't want to write it himself.

C) We add tabs at user/N/track/subscriptions and tracker/UID/subscriptions for all nodes that you've subscribed to. We move the current user/N/track tab to user/N/track/posts and we debate later which one is the default tab at user/N/track. ;) This is mostly an issue for David and tracker2. Edit: Moved to #404084: Add support for tracking flagged nodes

D) We change the default view for "My issues" so that it uses flag instead of the current "posted or commented on" behavior if flag.module is enabled. I'll handle this.

E) We add a new user/N/issue-subscriptions tab for every user, with the following parts:

E.1) A global, site-wide knob for "Email me issues from any project" with choices for "All issues", "Subscribed issues", and "None". We store this *separately* from the per-project stuff. This is a new, per-user table, {project_issue_user_subscription} or something.

E.2) A table of any projects where the user has configured emails on a per-project basis (e.g. http://drupal.org/project/issues/subscribe-mail/drupal). The table shows the current settings for each project, and includes a row with an auto-complete text field to opt-in for emails to other projects. Again, the choices are "All", "Subscribed", and "None". "None" removes that row from the table. Possible feature-creep: a component filter here?

E.3) Other global, site-wide knobs per aclight in #95 (e.g. #219751: Add a master subscription setting to receive all issue email notifications and #15380: Format issue mails as proper digests). These also go in {project_issue_user_subscription}. Perhaps we want to add project category and status filters here, too? Edit: Moved to #397458-6: Revamp mailing logic to leverage flag module

On the "get killes to agree" front, the only outstanding issue is #404038: Split out Admin Pages into flag.admin.inc, and in IRC, quicksketch agreed he'd be willing to just take care of that himself in the interest of time and efficiency.

#404038 is step 0, and a blocker before we can deploy on d.o. After that, only (A), (B) and (D) are absolutely required to make an initial improvement. (C) needs to follow quickly, but could potentially come a few days later if tracker2 isn't flag-aware when the rest is ready to go. (E) needs to happen soon, but relatively speaking, it's a minority of d.o users (~4500 have any issue subscriptions enabled at all right now). So, that could in theory wait for phase 2. However, unless C, D, and E are all fixed relatively soon after each other, we'll be stuck with some people still "+1 subscribing" because that's the only way to get things to show up in their preferred workflow.

Are we all on the same page now? ;)

p.s. I didn't see any of #97-#103 when I posted. Looks like #104 addresses most of what sun said at #97. Certainly on the issues themselves I'd be happy to have a counter of how many people are subscribed to the issue. I'd consider putting it in the issue queue tables, too, but a) that's a separate feature request and b) I'd have to be convinced it's really worth the extra bloat in the size and complexity of the table.

#104.C is now at #404084: Add support for tracking flagged nodes. David doesn't have time to work on this this week. So, anyone who wants to concretely help move this forward is encouraged to volunteer there, assign themselves that issue, and produce the patch. Thanks!

And #104.E is now at #397458-6: Revamp mailing logic to leverage flag module

To facilitate this change, we started a chipin to raise funds so myself, hunmonk, and davidstrauss can focus on this and get it done (instead of doing other paid work that keeps our landlords happy but doesn't benefit the entire Drupal community). See http://3281d.com/2009/03/27/death-to-subscribe-comments for more (and to contribute). ;) Thanks!

Regarding actions, Rules scales well, according to #399292: Scaling questions.

Another recent update that should assuage concerns about the engine being too large was also solved in #397218: Decouple Admin UI and support "foreign" UIs.