Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.The tagging works well, but there is no way to display the list of issues tagged with some terms with their status, category, priority, etc.
A View would be ideal, but the current code of project_issue is not really Views-friendly, and Views doesn't run on drupal.org anyway.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 354340-project-issue-integration.patch | 15.14 KB | damien tournoud |
| #3 | 354340-project-issue-integration.patch | 14.82 KB | damien tournoud |
| #2 | 354340-project-issue-integration.patch | 14.76 KB | damien tournoud |
| #1 | 354340-project-issue-integration.patch | 14.58 KB | damien tournoud |
Comments
Comment #1
damien tournoud commentedThe following patch:
- create two new paths: project/issues-term/ that list all terms and project/issues//term/ that restrict to a specific project number
- hide link terms for managed vocabularies
- generate proper links to the paths above when a term is displayed as a project issue metadata
Most of the code for this is borrowed from the taxonomy and project_issue module, that offer no easy way to cooperate in D5 version. This is meant as a stop gap before a better (Views based?) solution.
Comment #2
damien tournoud commentedFixed a small glitch with feed channel.
Comment #3
damien tournoud commentedFix AND queries.
Comment #4
damien tournoud commentedcomment_alter_taxonomy_project_select_nodes() was really too ugly (because taxonomy_select_nodes() is...). I rewrote it.
Comment #5
damien tournoud commentedCommitted (with slight modifications) to both DRUPAL-5 and HEAD.
Comment #6
aclight commentedHm...I wish you had given me more than an hour to take a look at this and respond before you committed a big feature addition. I'm really not sure that this is the right direction to go right now. I think it might have been more appropriate to do this in the drupalorg module for d.o and then in the D6 version of cat try to integrate with project_issue better, since it will use views.
I haven't had time to look at this patch at all, but I would appreciate it if you would allow time for review and/or discussion before making major changes to the module.
Comment #7
damien tournoud commented@aclight: there is no major change in the c_a_t module itself: the new code is all self-contained in a separate .inc. Because this can benefit D5 sites other than d.o, I see little value in moving all this to the drupal.org module, but of course, it can be done :)
Otherwise, everybody understand that this is only a temporary solution... and that a better solution will be Views based... we will have to convince killes :)
Comment #8
aclight commentedI'm not sure what you mean about we have to convince killes? The D6 version of project* will require Views. I don't think anyone is arguing that. I know that for a while d.o was even running views, thought killes might have disabled it for the moment since no actual views were in use. The D5 version of the project_issue module even exposes its fields to Views and includes a few filters and argument handlers.
I realize that this patch is mostly an additional .inc file, but that's still part of the module, just not the .module file.
You've created a path that is in the project* namespace but isn't reserved by the project* namespace now, which could potentially cause conflicts on d.o. Right now, I get a page not found at http://drupal.org/project/issues-term. I'm not quite sure why that is.
Basically, you've added a lot of code to the module, most of which is copied from other modules, so that Views doesn't have to be run on d.o. If killes wants to not run Views on d.o while we're running D5, that's his decision. But I don't want comment_alter_taxonomy to have to take up the slack for the decision of our infrastructure team. That's why I think this needs to be in the drupal.org module. If you want to add views handlers in comment_alter_taxonomy to support tags on issues (if that's even necessary), then that's fine.
If killes is not willing to run Views once d.o is upgraded to D6, then I think he will have many more problems on his hands, and we don't need to worry about that potential at the moment.
Comment #9
hunmonk commentedsooner or later, d.o is going to have to run views. we're coding project module to use views in 6.x, so i that's the latest it's going to happen.
i'm in agreement with aclight here that any custom code that hacks around a lack of views should not be in this module.
i'm also not crazy about adding any more items to the reserved namespace under project/*. i think we should adjust this if possible.