[META] Port issue following functionality to D7

I started looking at this and I think there are a couple of approaches that we could use to solve this issue.

1. Port the current patch mentioned above to tracker in d7
2. Create a new contrib module that provides the generic user tracker functionality above
3. Use the existing: subscriptions module

Option 1 Update the tracker module like tracker2 was updated. Advantage: Simple, the diff is ready, just needs to be applied to the d7 module. Disadvantage: need to change a core module.

Option 2 is simpler to accomplish, but could be a little harder to code cleanly. Mainly because it would require the use of "internal" functions from tracker. that could be solved by a) ignoring that they are internal functions and just use them. b) create wrappers that are not internal.

The integration with the issue module would be nearly identical for both options 1 and 2.

Option 3 Create a "flag interface" that allows users to subscribe and unsubscribe from nodes using flag and subscriptions. The module seams like it would handle the mechanics of subscription, but would require an additional module for custom emails, and would likely bring with it a number of new options and workflow decisions. I don't know enough about this module to assess it's feasibility.

Integration would likely need to be rethought.

4) I've had bad experiences with this framework on the D6 side, and it wasn't entirely positive, and I've recieved similar feedback from others. It was difficult to work with and buggy. The drupal 7 version is in Alpha so I'm skeptical that it's mature enough either.

5) I'll poke at rules today, and get back to you. I'm curious about performance, but it might not be an issue.

I'm with you 100% on the priorities.

I'd like to see a generic flag_tracker solution for d7. I think it's a no brainer useful module, unless you don't "need" a module and can do this with flag + rules (in a performant fashion). More after I've discovered more with this solution.

Tagging.

Awesome, thanks for researching that angle, anyway. It's good to be able to rule it out and have sound reasoning as to why.

The only thing I'd question is if those custom actions we'd have to write for Project Issue would be useful at all in other contexts; for example, in Views Bulk Operations for mass issue queue changing.

Sorry to be offline for a bit, one project ends another begins, and meetings meetings meetings. I'm in agreement with all the comments about rules, and email notifications. There isn't a good generic solution, so porting the old working stuff to d7 sounds like the most reasonable path.

For the follow functionality I'm thinking that a generic flag_tracker module is the way to go. Project issue can then use it, or we simply configure it to allow following of issues.

Tagging for Sprint 3.

Rules Link should be a 6th option on the list. It meets the mentioned requirements of views integration, similar to vbo without bulk op, but is more lightweight than flag.

I originally advocated for flag, #34496-26: [meta] Add Flag module to allow users to subscribe/unsubscribe without posting a comment, well before the Rules Link module was developed, but it has since become a powerful alternative for all things flag can do minus the data storage.

The user subscription manifest would then need to be put in a manually created table because Rules Link does not provide a storage mechanism, ie user_followings=nids.

There are a few examples of it in Johnan's screencasts, http://dev.nodeone.se/node/1067 http://dev.nodeone.se/node/1068 and Rules Workflow project. Obviously, a subscription/following feature would be a little more impactful example...

Tagging for Sprint 4.

Yay progress. http://drupal.org/sandbox/mirzu/1649546

This is the work in progress for moving the flag tracker code out of the issues and into it's own module. The meat of it works (it's a direct port of how it worked in 6). Today I hope to have it cleaned up and have added forms that allow users to select a flag per content type and globally. After that I'll create a patch that moves the code out of issues tracker that is made redundant.

The Flag tracker module: http://drupal.org/sandbox/mirzu/1649546 is now ready for testing.

Try it out:

1. download and enable the module (flag and tracker modules are required)
2. Create a flag if you don't have one, insure that the flag is useable by the content type you want to enable tracking for.
3. On any content type you should now have a new Flag Tracker vertical tab
4. Select your flag for this content type.
5. Create some content in that content type
6. Log in as a different user and flag the content you created.
7. view that user's tracker page (user//track)

Next is removing the bits of this that are duplicated in the project_issue module.

Few quick things:

1) Line 11 of the .module file, there is an extra indent.

2) I do not get the content to show up on user/{UID}/track.

3) On the flag that is pre-created you also have to choose to show it on the node and node teaser. Not sure if there is a way to fix that (or if we should).

#2 is the only one I am worried about, IRC mayhaps to chat about it?

I just tested the most recent update, the new module code works great. Now just need the code to remove said functionality from the project_issue module.

Since this issue and #1571400: Port auto-closing functionality to D7 are a bit commingled, I'm mentioning here that I added some info Re: 7 in the later parts of my comment in that issue. It's not at all meant to disrupt efforts on the existing porting. It's a parallel contribution, on my part, so that good options aren't forgone, especially from the above evaluation which needed some corrections.

There's a base set of functionality for tracking available in Track N Notify. It's a proof of concept (in the sense that it uses features and a track node-type instead of an entity), however despite its incompleteness, it's functional and extensible.

Other elements like email queuing, a view for # of followers, and a view for whose subscribing will be simple enough additions. User digests and per-project subscription management are probably higher priority features, so that's what I'll focus on next. That's all for now.

Attached is a patch that sets up project issue to use the flag_tracker module. There is likely some work still to be done, and I have a number of questions about a couple of things, but I figure it's better to post something at this point than to keep this under wraps.

Questions:
I'm not sure where this is called project_issue_flag_issue() greping for it only comes up with the one instance, so I'm not sure how to change it.
Where are the variables for the project-issue-summary.tpl.php generated? I couldn't find it.

Talked about this in Project Project Scrum. I'm going to investigate how the project_issue_flag_issue() is used in the d6 version.

I've updated the patch to use new settings included in the flag_tracker module. Should work correctly now and include the number of followers. Once the layout of a project issue page is finished should be an easy task to output the flag in the template. Shouldn't need to do anythine more than place the flag using the recomended method from the flag module. http://drupal.org/node/295383

<?php 
  $node = menu_get_object('node');
  print flag_create_link('project_issue_follow', $node->nid);
?>

Fixed a couple of spelling errors found by Rob.

I read through the code for both this patch and the flag_tracker module that mirzu has in sandbox right now. We made a few small changes (typo type things). I tested on my own dev environment and we walked through setting it up, I followed and unfollowed an issue as admin and a test user, and checked the "Track" tab on the user account page. We fixed one error message that was popping up when you were the last person to unfollow something.

Also we ran a coder review.

This looks good to me !

Awesome!! Marking rtbc :)

Reviewed and committed, thanks. http://drupalcode.org/project/project_issue.git/commit/ace2c5e

I made a slight change in includes/notification.inc to avoid crashing in _project_issue_notification_levels on the user/%/project-issue form. (Note that this form does crash again later, but that's #1560012: Port per-user issue notification email functionality to D7's problem. ;)
http://drupalcode.org/project/project_issue.git/commit/746df4a

Mirzu, you're planning to promote your sandbox soon, right?

Tagging for Sprint 6.

promoting tomorrow.

#1828756: D7 views don't honor tracker and issue following is now done.

...restoring tags eaten by the tag monster.