The [#XXX] filter is fricking awesome. Drewish and I were talking, and we would love to have that on g.d.o so that http://groups.drupal.org/patch-spotlight was a bit easier to maintain. Seems like we could do this with the addition of a "database to go get the issue data from" setting (which would only appear if there were multiple $db_url string defined in settings.php) and db_set_active() over to that before doing the query.

But then I got thinking about it, and it would be even more awesome if it could work from *anywhere* on the net, but this would require screen-scraping d.o to grab the title, and breaking this functionality out into a separate module. Because I don't think g.d.o wants to run project_issue module, and I could then use said filter on webchick.net or drop.cwgordon.com to setup custom issue lists.

So... not sure what you think. Wanted to post this anyway to see. :)

Comments

aclight’s picture

aclight commented

Sounds like a bit of a nightmare to me :) This would have to assume that anyone can access all issues, I believe. Also, this filter is currently in the project issue module, so unless g.d.o is going to run that module we'd need to break the filter into a separate module anyway.

I agree that this would be really nice functionality. I wonder if it wouldn't make more sense to have some kind of data API that project_issue could implement that would export the issue node information via an interface that another site could use. I think this would be a better longer term solution, though I don't have any experience doing this kind of thing.

scor’s picture

scor commented

true this is an awesome idea which would be one use case of #134478: Refactor page (and node) rendering. Every node and its fields would be accessible in JSON for instance: you could get the title and the status of an issue very simply, no need for screen-scraping :)

dww’s picture

dww
we/he/they
commented

If we really want to fix this (and #318623: [#nodeID] should work for all d.o. nodes while we're at it), then there should be:

A) An XML-RPC interface to get summary info about a given nid at a given host.

B) A hook that this interface invokes to let other modules add data to the returned XML.

C) The filter should support both [#nid] and [#url] syntax. If it's a URL, it should do an XML-RPC request to the given URL, asking about the specified nid. If it's a nid, it should basically just natively invoke the same hook that the XML-RPC server invokes to get whatever info is relevant to display in the mouse-over (whether that's issue status, last-modified date for a handbook page, whatever).

D) I guess you'd have to do XML-RPC auth if you wanted to ask for info about a node that anonymous users don't have permissions to view, and then you'd get into all sorts of tricky goo with the filter configuration not being cachable, etc. This will be a big nasty can of worms.

We should probably split out the filter into a separate module, that comes with both a client and server modules. So, we'd run the server module on d.o, which would invoke a hook that project_issue would implement. Then, any site that wants the filter enables the client module and configures it appropriately.

Raising money to fund this development is left as an exercise for the interested reader. ;)

drewish’s picture

drewish commented

i think it'd be a really great feature but it's got some big hurdles as dww laid out.

i'd suggest against proving open access to this on d.o because it'd start getting expensive when a few sites clear their caches and then view a pages listing a couple hundred #234: "catagories" in taxonomy_html module links. so that suggests doing something like the services.module where you could easily add some authentication.

drewish’s picture

drewish commented

i think it'd be a really great feature but it's got some big hurdles as dww laid out.

i'd suggest against proving open access to this on d.o because it'd start getting expensive when a few sites clear their caches and then view a pages listing a couple hundred #234: "catagories" in taxonomy_html module links. so that suggests doing something like the services.module where you could easily add some authentication.

pasqualle’s picture

pasqualle
Location 🇭🇺 Budapest
commented

my dream:
1. upgrade project*+issue tracking to D6
2. add project* support for the services module and deploy it on d.o
3. read and use the Drupal issue queue just as you like it..

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

I'm working on a module that will eventually entirely replace the current project_issue filter.

However, exposing an interface to query d.o data would still be required, but I guess that's rather the point of #112805: JSON menu callback for project issues