Create a block that shows the issue metadata

It seems that there is a number of ways to display project issue fields in the side bar.

1. By just moving them with page_alter into the region
2. Creating a module that would display a block with fields for project_issue node type
3. By not actually moving the fields out of $content into $sidebar but just wrapping them with container inside of node content and displaying them on the right. Something like float or absolute positioning if we have to
4. Showing the fields inside of one of the tpl.php files.

In the end it probably makes sense to discuss this with Bluecheese Team to make sure approach taken incorporates their goals as well. So far the fields have been moved around with page_alter and it works but there are some issues with the zones and they fields are missing a wrapper so it still needs to be adjusted.

Also not sure how this will work with issue edit form. So this is definately something to be considered as well.

I will research the issue further as well and hopefully try and throw some code together as well.

This was missing from the patch.

The patch above wouldn't apply to the latest bzr version of bluecheese... I got most of it to apply, and made this new patch. I don't know how to make bzr diff include missing files in a patch, so the missing files are in the attached tar.gz file.

I'm going to take this over. What needs to be done:

- The programming code in the patch above from bsmirnov needs to be moved into the drupalorg project as much as possible. We should only be making CSS patches to bluecheese I think. Don't commit the patches above!

- We need it to match this mockup a bit better (like having : after the labels and the status needs to be separated):

- Merging with this issue #1706520: Add a "Follow" button to the issue metadata block (so I'll be adding the buttons too).

OK, I've got this working.... Attached:
* css-only-project.patch -- patch for Bluecheese, without the additional files (don't know how to get bzr diff to include them).
* new-added-files.tgz - additional files for Bluecheese to go with the patch.
* project-issue-sidebar-1696872.patch - patch for drupalorg project.

A few notes:
- I took out all the stuff from bsmirnov's patches above that was not relevant to this one particular issue.
- I completely changed the way this was being done: it's a real block now, and the PHP code is all in project drupalorg and not in the theme.
- I had to comment out some stuff in the drupalorg_project.info file in order to enable the module (missing dependencies).
- After applying these patches, you need to go to Blocks and add the "Issue meta-data" block to the Sidebar Second region.
- Not sure about the issue status/priority colors either... but those are easy to change in the CSS.
- The "update this issue" button needs some styling help from someone who is good at CSS.
- The "Follow" button also needs to be added (something with Flag).
- There are a couple of other ToDos in the code. (marked with @todo D7).

I'm moving this to the drupalorg project now since that is where the main patch is going.

Probably all I can do on this one...

If we can get the above two patches on Bluecheese and Drupalorg committed today, that would be good.

Then we can bzr update the project dev site, and I can restore the unrelated parts of Boris's work so he can continue to work on theming the Issue page (there was some stuff he did on comments that is not currently up there, but has been saved as part of the previous patches).

I think it'd be reasonable for project_issue to provide this block itself. I'll hopefully have a chance today to move that part of the patch into project_issue and commit/push that. drupalorg_project can still hide the metadata fields from the issue in hook_node_view(), but it seems like the block itself is potentially useful to many sites, not just d.o...

Thanks,
-Derek

That sounds like a good plan.

Do you want to put the CSS into Project Issue too then, or leave it in Bluecheese?

Most of that CSS looks bluecheese-specific, but the colors for the status + priority stuff could live in project_issue.css I guess.

However, I'd love to have a better system for how the colors associated with issue status values worked. Since you can define the status values in the UI, it'd be nice if you could somehow map those directly to colors right there, instead of having to hard-code everything into the themes. I'm just not sure how all that should work. ;) I thought I already had an issue open about this, but a quick search isn't turning up anything...

OK... Then I'll let you sort out the CSS then into Bluecheese vs. Project Issue, and make new patches. Hopefully the patches in #8 will at least give you a good start. :)

As far as Boris's stuff (see comment #10), I think what I'll do on the Project Dev site is just revert all of what's in the patches in #8 (the stuff specific to this meta-data block), and restore the comment-related stuff from the earlier patches, so Boris can continue to work on that tomorrow.

Well, the project dev 7 site is in a weird state so I'm not going to do anything to it. What I did do is make a new patch for Boris (I'm sure there's a better place to put it but I'm not sure where) that just includes the comment-related stuff (plus a bit that was not possible to extricate that is related to the meta-data). You'll also need the "added files" zip from #8 above.

As a general policy, please keep additions to template.php minimal. drupalorg module is a better place for custom PHP.

Crap, I wanted to get this done before heading out to a memorial service, but I'm running out of time. :( Here's what I've done so far:

- Got project_issue_block_*() stuff ported over at #1712314: Port "issue cockpit" block to D7
- Moved the block definition here into project_issue
- Fixed the drupalorg_project code to handle that many node types might be issues

TODO:
- I don't like how project_issue_issue_metadata() works at all. As I mentioned at #1628122: Implement table of current issue metadata values when viewing issues it'd be nice to have a better system for what fields show up in this table than hard-coding everything.
- The actual code in here to map values to CSS classes and stuff is also way too hard-coded, and needs to be re-thought.
- I didn't touch the CSS itself, either.

Sorry I couldn't get this further along, but I need to run so I wanted to at least post my work-in-progress and provide an update on where things stand.

Thanks/sorry,
-Derek

Now that #1628122: Implement table of current issue metadata values when viewing issues is done, complete with a new view mode for issue metadata, this was significantly easier. So, I just pushed a few commits, both for project_issue and drupalorg_project:

http://drupalcode.org/project/project_issue.git/commit/c6a41fe
http://drupalcode.org/project/drupalorg.git/commit/1af63ba
http://drupalcode.org/project/drupalorg.git/commit/bda8c0c

Still TODO:

• Adding the update button, although that's a job for #1628042: Implement the "Update this issue" button when viewing an issue. We can just add it to the issue-metadata block as part of that issue.
• Rendering the priority and status as special cases, wrapped in classed divs. The previous approaches for doing this seem wrong. I'd propose:
  • Use the value of the field as the class, not trying to convert it to a human-readable class name. E.g. "priority-100" and "status-2" not "priority-normal" and "status-needs-review" (or whatever).
  • Have a field formatter that injects the appropriate class into the value's <div> instead of trying to do it manually. However, we shouldn't write this ourselves. Surely it must already exist somewhere. In fact, it's almost surprising you can't just get that behavior directly via core. If not a whole separate formatter, at least a setting on the existing one.

  IMHO, we should split this part off into a separate issue so we can call this one fixed (since we do have the block itself now). See #1721776: Figure out how to render the status field with markup that includes the status value as a class

• Bluecheese's own CSS for this stuff. I'd definitely object to a system where we use different CSS + background colors for status values in this table vs. the colors we want to use for our issue queue views, #1628160: Port issue nid field formatter to D7, etc. Even if we don't do something slick to let it be controlled via the UI, we definitely need to maintain a consistent set of colors and ideally just define those once in the CSS and ensure that all these other places reuse the same classes such that the 1 set of CSS selectors and rules applies in all cases. Again, I'd propose a new, clearer issue for this part. See #1721772: Ensure a unified system for status-based issue coloring throughout the UI

Split these off into separate issues:

#1721776: Figure out how to render the status field with markup that includes the status value as a class
#1721772: Ensure a unified system for status-based issue coloring throughout the UI
#1721768: Allow site admins to associate colors for issue status values via the UI

I think this should be considered fixed at this point: we have a working block for issue metadata, and we have follow-up issues for all the other stuff related to this. If we need a bluecheese issue to track other stuff, please open a new issue.

Thanks,
-Derek

...I don't know if we're still going with the mockup in #7, but I don't think that adding status text in the "Update this issue" and "Follow" buttons is such a good idea. Buttons should generally only include text that prompts for action and that alone.

FYI: I just pushed a follow-up fix to only show this block when viewing issue nodes, not on edit (where it's confusing as hell) or delete (where it's not needed):

http://drupalcode.org/project/project_issue.git/commit/613004b