Add an "issue cockpit" block for project nodes

Sweet, this is definitely getting closer. A few remaining problems:

A) It just prints out "( open)" for projects that have 0 open issues in a given category.

B) The default "create new" button (e.g. at http://drupal.org/project/issues/drupal) is actually labeled "Create a new issue", but the help text here says "handy 'create new' button". It's also a link, not a button. And maybe "handy" isn't the best language for this. ;) I know you're just exactly implementing the screenshot I posted, but that was just the general direction. I think you should feel completely empowered to improve the text or UI in any ways you see fit. ;)

C) Even though it's a smaller font, all the "total (N)" links draw a lot of my attention. I think it'd flow better (and save vertical space) if we tried it as:

Feature requests: 0 open, 1 total

It would be nice to leave all of "Feature requests" a link, too. Is this too weird?

Feature requests: 0 open, 1 total

D) Not sure, but wouldn't it be nice to be able to retain this block once we land on a given project's issue queue page? Seems slightly disorienting that after you submit the search box form, you're sent to a page where the block disappears (and, due to how the breadcrumbs work, there's actually no way to get back to the project page you were just viewing).

Made a few changes:

- Fixed bug where the advanced search link was broken
- Added a "Subscribe via e-mail" link
- Moved the .inc file into includes and the .tpl.php file into a new "theme" directory
- Slightly changed the formatting of the block: "Feature requests: 0 open (1 total)" (at least for now)
- Added some PHPDoc to the new functions

Committed to HEAD:

http://drupal.org/cvs?commit=195420
http://drupal.org/cvs?commit=195426

Thanks!

When this is deployed, we need to make sure we deploy both project and drupalorg.module at the same time (since the link sections it's trying to alter will be different). We also need to actually enable this block for bluebeach. The block itself is smart about only showing up on project nodes, so we just need to configure it to always appear in the right side-bar and give it the right weight.

FYI: this is now deployed on d6.d.o so folks can see how it looks:

http://d6.drupal.org/project/drupal
http://d6.drupal.org/project/project
http://d6.drupal.org/project/views
...

What do y'all think?

Also, I think we're going to want to roll our own caching for this block. The core block cache is going to be invalidated every time a comment or node is posted on d.o, which is going to be probably too frequently for that cache to do us much good. :(

Here's a screenshot of what it looks like in "bluecheese", the redesign theme...

Yeah, I fixed the "Search" button and "Advanced search" link. I also did some other cleanup based on feedback in IRC the other night:
http://drupal.org/cvs?commit=199814
For example, there are now checkboxes when you configure the block to decide which categories you want to see the summary lines for. The general agreement was that seeing 'All issues' and 'Bug reports' was all you really need. But, instead of hard-coding those into the theme template, it was just as easy (both to code and to change) to make it a setting. So, if we ever change our minds and want to see other summary lines in there, it's a few clicks instead of dealing with the theme template.

This could probably still use some custom block caching, so still leaving this as "needs work"....

Now with custom caching for this block... This was a bit thorny to invalidate the block cache for the right project(s) when comments are added or deleted, but it's all working now. ;) I'll deploy this on d6.d.o for folks to play with it and see if they can break it.

This is now deployed on d6.d.o for testing:

http://d6.drupal.org/project/drupal
http://d6.drupal.org/project/project
http://d6.drupal.org/project/views
...

If you add comments or new issues in any way that affects the totals for a project (e.g. new issue, moving an issue to another project, reclassifying a support request to a bug or vice versa, etc), you should see the totals change on all the relevant project node(s).

I also deployed the latest changes to bluebeach's style.css on there. Any final suggestions or problems before I deploy this for real on d.o?

@hunmonk: Thanks for the review.

Re #20: Because I've been repeatedly burned by the lameness that is core's cache API. For example, see #319486-3: Fetched update informations at every cron and beyond. One of these days in the near future, I have to write a patch for core to convert the cache table that update.module uses to make it not a "real" cache table so that it actually friggin' works for what it's supposed to work for. :( It's currently impossible to have non-volatile caches with the core cache API. To avoid jumping through a bunch of hoops, e.g. changing the memcache configuration on d.o when I deploy this change, I'm just doing my own table and cache API. Either we should use core's useless block caching (which will clear the cache effectively all the time -- no thanks), we shouldn't use any caching at all (and hope all these new queries don't piss off the DB maintainers), or we should have our own cache table so we can actually control when the cache is cleared and clear it at appropriate times (which is what this patch does). Yes, it'd be "nicer" in the abstract to use the standard mechanisms, but until those mechanisms doesn't actively harm things, I'm not going to be using them.

Ok, after my experiences with #220592: Core cache API breaks update.module: fetches data way too often, kills site performance, etc and longer discussions with killes about memcache and friends, I've changed my mind on this a bit. I'm willing to use the core cache API (and the default {cache} table in fact) based on the following:

- So long as you use CACHE_PERMANENT (the default), the core cache API isn't quite as terribly broken as it seems.

- Sites that have a TON of projects are likely to be drupal.org and therefore, using memcache. Memcache will be faster/better for this than a separate table. Sites that don't have a ton of projects aren't going to care about a few blocks being cached directly in {cache} for this. It's certainly better than the core block cache since we invalidate at the right times, unlike {cache_block}.

- The volatility of the cache API and memcache isn't *that* big a deal for these blocks -- so we have to run a few (semi) expensive DB queries -- big deal. It's not like we've got to fetch data from updates.d.o or anything truly expensive.

So, here's a new patch that adds caching using cache_set|get and the default {cache} table. Tested locally and seems to do the right things. Any final complaints before I commit and deploy?

Cool, committed to HEAD. Just needs deployment (along with the rest of this block). bluebeach already has reasonable CSS for this block, but bluecheese needs some.

Now deployed.

Setting this back to "needs work" for some bluecheese CSS lovin'...

@longwave: Thanks! Reviewed, tested, and committed to HEAD. I patched d.o as a temporary workaround, but we should really officially deploy this change via our usual SVN + vendor branch setup, so tagging as such.

Back to "needs work" for the bluecheese CSS...

@greg.harvey: Thanks for suggesting that, I see what you mean. However, I can definitely argue both sides of it... Most of the blocks on project nodes are specific to that project -- do we really want to duplicate "... for views" on every block? E.g. "Maintainers for Views", "Issues for Views", "Recent issues for Views", etc.

This is only going to get worse as we get further with the drupal.org redesign, since there are going to be even more project-specific blocks:
#372580: Move the project node links to blocks
#372027: Create "Links" block for project nodes
#371979: "Get Involved" Block on project pages
...
For some (out of date) examples of what we're kind of working towards, see:
http://infrastructure.drupal.org/drupal.org-style-guide/prototype/core.html
http://infrastructure.drupal.org/drupal.org-style-guide/prototype/module...

Seems like a slippery slope to put project names on all of them. :/ Granted, given that we still have the non-project blocks over there with the current design, there's a stronger case for using the project name on the project-specific blocks in the mean time. So, I might just temporarily roll out this change, anyway. But, I wanted to raise the point that it probably shouldn't stay like this, if we do it at all...

A (minor) bug I just noticed is that since the help text about searching for duplicates is enclosed in a test if the user has permission to create issues (e.g. they're logged in), sometimes a version of the block is cached which doesn't have that text (if an anon user happens to be the first visit a given project page after the cache is cleared). We should probably rip out the test and always print the help text...

Except the core role+page block caching is useless on a site like d.o, since the *entire* block cache is cleared every time anyone comments on the site. :(

@mfb: Good question, I don't know. :(

I committed a fix to always display the help text, and also added the project title to the block title (for now).

Deployed on d.o as a local patch for now. I'm going to wait to officially deploy until some other goodies are fixed.

@mfb: some core issues to track related to this
#186638: Add a 'keep until' column for cache tables
#458808: Add a way to specify CACHE_PERMANENT for block caching

Ok, I deployed the latest changes on d.o.

Not sure what else is left in here. I guess it's bluecheese CSS + redesign stuff...

The project_issue feature is done, but from a redesign perspective, there's still more to do:

a) this block doesn't appear at http://redesign.drupal.org/project/drupal
b) last time I tried turning on the block with bluecheese, the CSS needed some help to not look so terrible

Where's the best place for such work? Should this be added to #693378: D&E: Modules needs sidebar content or a new issue in http://drupal.org/project/issues/redesign ?

Actually, it looks like the bluecheese changes for this block are in the patch at #843872: Work on D&E core (and project pages). I'd rather leave this issue for the feature request for project_issue (which is long done) and handle the bluecheese stuff in another issue. Seems we don't need a duplicate one given the link above.