Drupal.org should theme project issue links with "Assigned" and use the background color of the current "status"

I like the idea behind this, but I'm worried that it won't work as you think it will.

Since nodes on d.o use the page cache, and the page cache is cleared only every 24 hours, I don't think that changes to the status of an issue would necessairly show up in other nodes that referred to that particular issue using the project issue link filter. Maybe we've somehow fixed this in project* or elsewhere and I don't recall, but I was one of the reviewers for the patch and I do remember us deciding at the time that having data that was stale up to 24 hours was an acceptable problem given the potential utility of the link filter.

But that aside, the proposed changes make references to issues quite long. I wonder if it might look ok to change the background color of the link to yellow, green, red, etc. instead of having the status spelled out next to it. We're all probably familiar enough with the colors for that to be enough. In addition, if there was any question you can always mouse over the link and the status will be spelled out. If we did this then we'd only have the additional width of the assigned to box, which isn't so wide.

I'm just not sure if having a red or green background on the blue links would make the links too hard to read. If that was a problem maybe we could just use a colored border around the link, and not fill the background with a different color. Or a dashed underline or something like that.

I don't know for whose ok you are waiting here? I think it's a good idea.

Since nodes on d.o use the page cache, and the page cache is cleared only every 24 hours, I don't think that changes to the status of an issue would necessairly show up in other nodes that referred to that particular issue using the project issue link filter. Maybe we've somehow fixed this in project* or elsewhere and I don't recall, but I was one of the reviewers for the patch and I do remember us deciding at the time that having data that was stale up to 24 hours was an acceptable problem given the potential utility of the link filter.

The page cache might not be a real issue, as most of us are logged anyway. Would the filter cache (not the page cache) could be an issue?

Yeah, I think Adam confused the page cache (which is cleared every few minutes) with the filter cache.

@aclight: issue list tables like http://drupal.org/project/issues-term/346 are using colored backgrounds with these links, and I think the colors were picked to work well with the link color. I am fine with the links having backgrounds.

Could we tweak the colors a little bit more so that critical issues stand out a little bit more?

My point of view is that a lack of overview for this redesign/upgrade is more of a problem then having an overview which is sometimes a bit stale.

I agree 100%. Go for it :)

@Gabor: I understand the idea of building a prioritized page listing. And now that I think about it, we only color by status, not by priority. Please scratch what I said in the first part of #8.

@all: Yes, thanks for pointing out that I meant the filter cache, not the page cache. And Gabor's point that editing the node with the listing of issues will clear the filter cache for that node is well taken. That of course is the driving point behind this issue.

But part of my point was that if we make the theming of links created with the project issue link filter more descriptive (in the sense that we're now making the status of the issue much more obvious and displaying the person the issue is assigned to), we risk that on other nodes/comments that use the pi link filter but which are not updated as regularly, the fact that the filter cache isn't frequently refreshed will be even more obvious.

I'm not sure if the improvement in the display of links created by this filter outweighs the problem of making it more obvious that the status information of these links may be stale. Don't get me wrong, I'd love to have links themed like this, but wonder if the potential increased confusion would be worth it.

For the sprint, we could do as Gabor suggested and create a new node type, and only apply this new theming of project issue links to that node type. That would give us the better display of issues for the sprint, but prevent the obvious display of stale data elsewhere on d.o.

Alternately we could try this out for a few months on all node types and see whether there are a lot of support requests or complaints of stale data, and if not then just continue with it.

I'm not sure if there is an approach to the underlying problem that will allow for the theming of the links to not be stale but not be a huge performance drain on the infrastructure. If there was a way around this problem perhaps the D6 version of this link filter could be modified and then d.o will get that benefit once it's running D6.

The user_load() is a bit overkill:

if (!empty($node->project_issue['assigned']) && ($account = user_load(array('uid' => )))) {

Could be easily replaced by:

$account = db_fetch_object(db_query("SELECT * FROM {users} WHERE uid = %d", $node->project_issue['assigned']))

A) Good idea, I'm all for it.

B) Today is the last day I've got family visiting for a long weekend, so I'm not going to be available to help much. :(

C) No time to test this, but the only problem I see on visual review is this comment isn't exactly accurate anymore:

// If the issue is assigned to a user, try to load that user and display the name here.

So, if you fix that, and you've tested all this and it works, this is RTBC to my eyes.

Thanks!
-Derek

p.s. When I'm back at it tomorrow (or perhaps late tonight), I was about to commit this patch: #359757: Add extra class (priority-x) to issue rows which would enable sites to, for example, use bold on the issue listing rows of critical issues. Since bluebeach already themes all links in bold, this wouldn't really help us much here, but I wanted to mention it so folks are aware.

I also think some stale information is no big deal. If folks do think it is a big deal, we could add an input format which does no caching and form_alter these issues so they are authored in that format. Just a thought ...

Ok, let's try this, then.

Looks great to me! There is a lot of information on one screen (it is quite wide) but it all seems very useful information to have. :-)

This has broken status CSS in the issue queue.

.project-issue tr.state-13 {b87ea00d...a79de.css (line 1)
background-color:#FFE7DD;
}

Is overwritten by:

body, .form-text, .form-password, textarea, th, td {b87ea00d...a79de.css (line 1)
background:#FFFFFF none repeat scroll 0 0;
color:#003150;
}

So all rows are white apart from the active column.

Now the zebra striping of the issue metadata tables seems to be broken. Before the row background alternated between gray and white, now all rows have a white background.

I think it might be related that the releases on the project pages (example: http://drupal.org/project/views) all have white background now, where recommended should have green, supported should have yellow and dev should have red.

the "won't fix" status is displayed as "Issue status: won't fix" in the tooltip. Tooltip does not work with html markup and special characters. I am not absolutely sure, but as I remember it was correct before this change.

example for a link with wrong tooltip: #262090: redirect by url alias

Yep. That's because in the theme function implemented by the project issue module, we have this:

$attributes = array('title' => project_issue_state($node->sid));

whereas the patch in #20 does this:

$attributes = array('title' => t('Issue status: @status', array('@status' => project_issue_state($node->sid))));

The call to check_plain converts the apostrophe into an HTML entity, but because the text of the title attribute of links is not parsed into HTML, the entity code remains. In the research we did when writing this function originally, we couldn't find any evidence that any browsers parse the text of a link title attribute, thus we couldn't think of how including the text without any kind of escaping/filtering could be a problem.

While I am largely in favor of this - especially for core - it is causing some heartburn for contribs. #367423: Make "assigned to" on issue links opt-in (by appending '@')