From what I can tell at a quick read of the code, this module doesn't actually need Flag.

This seems to be another example of that, judging by the Flag support requests, is something lots of people do with Flag: they use it for the shiny JS link that they can put on nodes, and then use the hook to cause something else to happen, such as Rules.

In this case, the module is calling _tracker_add() when a node is flagged. That does its own storage. So all the data is duplicated between Tracker and Flag, and this module has to work to keep that in sync in both directions.

Comments

mgifford’s picture

mgifford
he/him
Primary language English
commented

Would be great to get clarification on this in the docs.

joachim’s picture

joachim commented

Do you mean the docs for this module, or the docs for Flag?

An awful lot of people (who post support requests in the Flag issue queue) seem to be using Flag *just* for the shiny JS link UI. I have been thinking for some time that it would be of interest to extract that functionality from Flag, and have a module that provides JS links that can be placed on entities, cycle through 2 or more states when clicked, and do nothing apart from trigger Rules and hooks. Obviously, one for when I upgrade to 48 hours days or figure out how to clone myself :D

mgifford’s picture

mgifford
he/him
Primary language English
commented

@joachim I was looking specifically for this module. Particularly since it's used in drupal.org it would be useful to have a sense of how it should be used rather than just copying functions and reading the inline docs.

That's a neat idea about that JS link UI module though.

Probably easier than cloning yourself would be to find some way to engage more users in contributing code back to d.o.

It's always the dream that you could propose an idea like that, and someone else would go through the steps of implementing it. Sometimes it works.... And the more we are bringing new people into the community and exciting them with ideas like this, the more it is likely to happen.

joachim’s picture

joachim commented

It's now come back to me that I actually wrote up some notes on this: #2071245: [meta] Decoupling flag links from Flag and got as far as a rough proof of concept module for D8. For D7, I'd probably do this as a Display Suite field type -- though now I know d.org would likely be a user, that might not be so good an idea.

At any rate, the idea was that you'd define a new 'action link', say what entity types and bundles it goes on, define how many states it cycles through and the link text for each state, and that's about it.

joachim’s picture

joachim commented

Turns out it exists already: https://drupal.org/project/fasttoggle

joachim’s picture

joachim commented

I investigated https://drupal.org/project/fasttoggle for a client project yesterday, and it's not quite as far-reaching as what I was imagining. It is very much tied to acting on boolean properties of the entities themselves, and I don't think it could go beyond that without a total rewrite.

drumm’s picture

drumm
he/him
Location NY, US
commented

The way project_issue uses this module does hit both flag's data storage and the core tracker. Flag has a nicer API for checking who follows and issue.

The direction for this module should probably look forward to Drupal 8. It looks like the core tracker module has not modernized too much, _tracker_add() is still a private API.

For Drupal.org, #1304216: A user should be able to "follow" individual pages of content and receive email notifications for new comments could push this in the direction of relying more on Flag, and even removing tracker. If all the node types you might want to follow are covered by the flag, then https://www.drupal.org/user/3064/track can be a View based on the flag instead.

drumm’s picture

drumm
he/him
Location NY, US
commented
Status: Active » Closed (works as designed)