Tracker module: Add node type support and other fixes

This is a small train wreck. I just rolled-out a site that started under 4.5.1 and seemed to have no problems with a 4.5.2 upgrade. Now I see that the primary forum links (My forum discussions, Active forum discussions) are exposing raw tracker data, not confined to my 'Forums' vocabulary or published/not-published state.

Am I understanding correctly that this issue speaks of the same thing? A quick and dirty substitution of the revised tracker.module and forum.module (which had trailing blank lines) has not done the trick. I'm gonna have to hack-out those links or kill my forums *now*.

Here's what the "My forum discussions" and "Active forum discussions" links are exposing, respectively:

http://example.com/tracker/1
http://example.com/tracker

These aren't confined to my 'Forums" vocabulary at all. I'd appreciate learning what the proper link targets should be, so I can at least make a better hack. Even un-authenticated users are served http://example.com/tracker, with no permissions applied.

Need advice fast: What's the best short-term fix?

And I'm a little perplexed as to why tracker output listings aren't subject to permissions. Whether or not forum.module serves raw tracker links, someone could key their own URLs and get a listing of unpublished content. Even if they can't click through, my underwear's showing.

Any help appreciated. The other Drupal.org nodes/posts that come near this subject all have no replies. I hope I'm overreacting.

keywords: tracker.module tracker module admin private privacy broken forum forums 4.5 4.5.1 4.5.2 beta why wtf

Correction: Anonymous users *can* click-through to unpublished content by following forum.module's tracker links -- or tracker links in general. So it's not my underwear that's showing, it's my hairy, perfect ass.

Taking tracker.module offline. Fixed.

has this been fixed?

No, somebody should provide a patch.

I had the same thing happen and have posted the problem in several places. Tracker does not filter content. If you have any kind of permissions which restrict content, a restricted user can get at all of it through "recent posts." Major back-door flaw. Solution: very useful tracker module is deactivated.

Attached patch fixes:

• A 404 is now returned when the tracker for a non-existent user is requested. Currently, this displays a blank white page.
• Added node type arguments for both user/id/track/ and tracker/ and tracker/id/. The node type arguments will also accept + (or space) delimited arguments. So the following will all work:
  • /tracker/blog
  • /tracker/1/blog
  • /tracker/blog+story
  • /user/1/track/blog
  • /user/1/track/blog+story
• Values in the 'Type' column on the tracker page are now linked to the appropriate tracker links.
• IN() is faster when handling OR checks with constants. It is also supposed to be faster otherwise, but I have not confirmed this.
  i.e. id IN (1, 2); 1 IN (id1, id2); id IN (id1, id2); VS. their OR() equivalents.
• Removed ugly <br /> tag from the 'Reply' column. Replaced with <div>.
• Fixed help text. Removed link to profile page as this is related to the profile module which is not enabled by default.
• Forum.module: "My forum discussions" and "Active forum discussions" links corrected.

@jason et al.: I wrote the update from scratch, but I've had a quick look at the module submitted above. Things that I haven't done:

• Checking for the existence of the comment module and enabling/disabling the 'Replies' column: While this might be good, I as an end user will want to know whether there are any replies or not. I won't know that the comment module has been disabled.
• Adding menu items: These can be added manually. There can also be an infinite number of node types etc. etc.
• User 0: Anonymous user profile still comes up. I've left this issue alone.

@Lou Quillio: The unpublished content issue appears to be fixed.

If I've missed anything, please let me know.

Cheers
-K

This is a (nice) feature, not a bug. The handling of $type_query is a bit inconsistent. I'd prefer to put it completely into our db abstraction layer. I suggest to look into this when 4.8 development opens up.

killes: This fixes the forum page links ["My forum discussions" and "Active forum discussions"] bug, the 404 bug and the <br /> tag issue. I believe all of these are bugs. The added features are the multiple type query and the hyperlinked type fields, which are trivial once the above are accomplished.

I was going to make the tables sortable, but postponed that to post 4.7 as I'd like to see this patch go through.

$type query: Can you clarify on the inconsistency? The use of sprintf vs. concatenation?

I'm going to re-classify this as a bug. Feel free to reassign it as a feature if you still disagree :) I'll fix the code once you confirm what the inconsistency is.

Thanks for the review :)
-K

Attached patch:
- Keeps up with HEAD.
- Fixes my // form.
- Replaces sprintfs with . operators.

@Killes: I don't get what you mean.. The node types are already filtered out using the array_intersect(), and cease to be user input as such. So I don't see the benefit of running it through a filter once again. Please clarify.

Thanks,
-K

+1 for me. Really a good functionality to have.

This hasn't been updated in 6 months, but I think it's something that needs to be added (at least to drupal 6.0). I think the patch would still work, but with a few changes in the line numbers.

Do you still want this Zen? I might try to apply the patch by hand and come up w/ a new one.

There is actually another issue (hooray for people searching beforehand) that currently deals with this feature.

Marking this as duplicate.
-K

Heh, well, good try, but your search yielded the same post. I searched to see if you miscopied, but found nothing else under the tracker.module that was active.

Oops :/ Try http://drupal.org/node/83190

Cheers,
-K