the various links currently hard-coded under "Development" aren't always appropriate for all projects. the attached patch adds a checkbox to the admin settings page to control if these links are displayed or not (defaults to 'yes', the current behavior). the patch looks bigger than it is, i just had to indent a few things inside an if statement now. ;) let me know what y'all think and i'll commit it if i get the thumbs up.
thanks,
-derek
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | project_display_devel_links.patch | 4.3 KB | dww |
Comments
Comment #1
dwwtee hee, forgot to actually attach the patch. ;)
i should note: the patch intentionally moves the "View all issues" link up near the "view pending *" links since i think that's relevent for general support, even if you disable the "development" links. if someone strongly objects to that aspect of the patch, i'd be willing to re-roll one that leaves "all issues" with the development links.
Comment #2
nedjoThe page definitely could use improvement. A relevent previous issue: http://drupal.org/node/32841. But, as it is, won't this development section show only if it's appropriate, i.e., if there aren't issues and/or cvs-related data? Is there a use case there there are issues but we don't want to display links to them?
On the patch:
* The $links = array(); could go inside the if clause.
* We could delete the obsolete comment #$output .= while we're in here.
Comment #3
dwwthis setting just allows hiding the links to things refering to "patches" and "tasks". not all projects represent code that even *have* patches. this is one of my gripes with project... it just *assumes* you must be using it for something with source code that has patches. that's not always the case. killes will chime in and say "use casetracker.module instead", but then there are two seperate interfaces for users of a site that have both software and non-software projects, two different interfaces, etc, etc. i think that's lame. i'd rather just make project more flexible so it can handle both. this patch is a (tiny) step in that direction.
thanks,
-derek
Comment #4
nedjoOkay, understood.
This problem has two roots:
1. hard-coded issue categories
2. hard-coded issue status values (this one is more pernicious)
Any full solution will need to address these problems.
Meantime, a new setting is certainly one option.
Another would be testing for relevant issues and outputting the links only if there are some. E.g.
This would have the advantage of increased accuracy (no empty links), but at the cost of increased overhead.
Comment #5
dwwNo longer applies. I still think it'd be worth fixing this, but I agree we probably need a better approach than a simple site-wide setting.
Comment #6
dwwNow fixed thanks to #218571: add hook_project_page_link_alter(), implement to add security link to all project pages. There's no "setting" per se, but you can now alter all these links however you want in a site-specific module. That's probably good enough, at this point.