Jump to:
| Project: | Project issue tracking |
| Version: | 6.x-1.x-dev |
| Component: | Miscellaneous |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
| Issue tags: | Developer improvements |
Issue Summary
I just wrote the queries, so now it "just needs a page around it":
Top 10 issues by followers:select count(1), concat('</td><td><a href="http://drupal.org/node/', n.nid, '">', n.title, '</a></td></tr>') from flag_content fc inner join node n on fc.content_id = n.nid group by n.nid, n.title order by count(1) desc limit 10;
Top 10 issues by followers who didn't comment:select count(1), concat('</td><td><a href="http://drupal.org/node/', n.nid, '">', n.title, '</a></td></tr>') from flag_content fc inner join node n on fc.content_id = n.nid left join comments c on fc.content_id = c.nid and fc.uid = c.uid where c.uid is null group by n.nid, n.title order by count(1) desc limit 10;
Top 10 issues by followers who didn't comment based on follows in the last month:select count(1), concat('</td><td><a href="http://drupal.org/node/', n.nid, '">', n.title, '</a></td></tr>') from flag_content fc inner join node n on fc.content_id = n.nid left join comments c on fc.content_id = c.nid and fc.uid = c.uid where c.uid is null and fc.timestamp > unix_timestamp() - 60*60*24*30 group by n.nid, n.title order by count(1) desc limit 10;
Comments
#1
+1 subscribe
#2
It would be even more awesome to see this data per-project if possible!
#7
+1 for having this visible on the actual issue page, I think it's relevant you can see how many followers an issue has so you know if it's you who screwed up something or if there are a lot of people who face the same problem.
Can maintainers see what issue has the most followers in their queue ?
#8
@HnLn: that sounds more like #1304550: Display count of issue followers when viewing an issue
#9
cool, tnx, should have checked the issue queue first, my bad.
#10
+1 to the concept. It'd be nice to expose this info.
Can't this be done in views instead of hard-coded queries and display pages?
And yes, +1 to having it also available per-project, not just site-wide (although that's going to add another JOIN and a WHERE to the query, which will make it therefore more expensive).
Any thoughts/proposals on a URL structure for where these pages should live?
Thanks,
-Derek
#11
I thinks this is a really important tool which should be added ASAP. Having such important issue metadata hidden except to a privileged few is a real shame.
In an ideal world we'd direct would-be contributors to the most followed issues so the big ones get more attention, and resolved more quickly. This would be an invaluable tool.
This is just a vanilla View based on Flag integration with a little count() action, isn't it? Why do the OP queries need to worry about HTML in the query? Seems hacky, but perhaps I'm showing my ignorance of the internals here...
#12
Updating title and tag.
#13
The original queries are mostly useful for joins, not the columns.
Not as far as I know. The structure, as you probalby noticed, is just Flags so you could definitely create a mockup of the system on your local machine and export views here if it's that the case.