Add 'created' date column to issue queue views

That sounds reasonable, and thanks for providing a patch to implement your suggestion. However:

A) This should just be a patch to drupalorg_project, not a whole new module.

B) For this to be useful, you're going to have to alter more than just adding the field in the query -- you're going to need to insert that into the table, tell views that header is sortable, etc, etc. I don't think you can just alter all that via hook_views_query_alter. I think you want hook_views_default_views_alter(). Although I'm not sure how to get the extra field to show up in the table at run time depending on the argument off the top of my head, and I'm too tired right now to investigate.

C) There are separate views for the regular issue queue view and the advanced search. Check out project_issue for details. Presumably you'll want this field on both views, not just one.

Cheers,
-Derek

.

+1

this is sorely needed!

I'd like to review the query that gets generated.

@jthorson: did you apply for a d.o dev site?

"...the created date is already part of the existing views query"

I believe this is because of the "Node: Has new content" field.

This does need an EXPLAIN, and the created column being in the query as a field doesn't cover it.

Because the created colomn will be sortable, if you click the column heading, you'll get a query that orders by node created - that query could use an EXPLAIN (it should also run very rarely though).

Sorry for hijacking this issue, but I would really rather expand this to all projects on drupal.org. In a quick survey on IRC, this would also be helpful to at least Drupal core, CTools, Views, and Taxonomy Access maintainers, for the following reasons:

1. Without this, there is no way to tell how long an issue has been sitting around waiting to get fixed, beyond tapping someone with d.o SQL access.

2. It helps "bug squad" volunteers to prioritize where to start triaging issues; an issue that's 5 years old probably isn't relevant anymore. But someone might've commented on it in the past 2 weeks with a "Subscribe."

3. It also helps maintainers prioritize where to start committing issues; the lack of this causes issue tags like "Ancient" to show up because the only date-based info we have is when an issue was last commented on, which doesn't help us find burnt out contributors or truly languishing issues.

4. And finally, it helps stop demoralization of the folks applying for project access, who are our very lifeblood.

As a result, also raising priority to "major".

Coming up with a patch shortly.

Also +1, this is probably the only way we'll find the next node/8.

Ok, here's an initial patch which I think gets all of them. This is demoable at the following URLs:

(Apache user/pass: drupal/drupal; Drupal user/pass: bananas/bananas)

All projects: http://issue-summaries-drupal.redesign.devdrupal.org/project/issues
Projects: http://issue-summaries-drupal.redesign.devdrupal.org/project/issues/drupal
Search all: http://issue-summaries-drupal.redesign.devdrupal.org/project/issues/search
Search project: http://issue-summaries-drupal.redesign.devdrupal.org/project/issues/sear...
User issues: http://issue-summaries-drupal.redesign.devdrupal.org/project/issues/user
User projects: http://issue-summaries-drupal.redesign.devdrupal.org/project/user

Still to do:
a. Need to do an EXPLAIN on this new query, sorted by created timestamp.
b. There are a bunch of logic customizations to the views export that PI was doing that I need to reincorporate. Bleh.

Ok, here's the EXPLAINed query that's generated with the original view at http://issue-summaries-drupal.redesign.devdrupal.org/project/issues (sorted by last updated), just as a baseline.

mysql> EXPLAIN SELECT node.nid AS nid,    node_project_issues_1.title AS node_project_issues_1_title,    node_project_issues_1.nid AS node_project_issues_1_nid,    node_project_issues_1__project_projects.uri AS node_project_issues_1__project_projects_uri,    node.title AS node_title,    history_user.timestamp AS history_user_timestamp,    node.created AS node_created,    node.changed AS node_changed,    project_issues.sid AS project_issues_sid,    project_issues.priority AS project_issues_priority,    project_issues.category AS project_issues_category,    node_comment_statistics.comment_count AS node_comment_statistics_comment_count,    node.type AS node_type,    node_comment_statistics.last_comment_timestamp AS node_comment_statistics_last_comment_timestamp,    users_project_issues.name AS users_project_issues_name,    users_project_issues.uid AS users_project_issues_uid,    'project_issue_all_projects:page_1' AS view_name  FROM node node   INNER JOIN project_issues project_issues ON node.nid = project_issues.nid  INNER JOIN users users_project_issues ON project_issues.assigned = users_project_issues.uid  LEFT JOIN node node_project_issues ON project_issues.rid = node_project_issues.nid  INNER JOIN node node_project_issues_1 ON project_issues.pid = node_project_issues_1.nid  INNER JOIN project_projects node_project_issues_1__project_projects ON node_project_issues_1.nid = node_project_issues_1__project_projects.nid  LEFT JOIN history history_user ON node.nid = history_user.nid AND history_user.uid = 1  INNER JOIN node_comment_statistics node_comment_statistics ON node.nid = node_comment_statistics.nid  WHERE (node.status <> 0 OR (node.uid = 1 AND 1 <> 0) OR 1 = 1) AND (project_issues.sid in ('1', '13', '8', '14', '15', '2', '4', '16'))    ORDER BY node_comment_statistics_last_comment_timestamp DESC  LIMIT 0, 50
    -> ;
+----+-------------+-----------------------------------------+--------+---------------------------------------------------------------------------+------------------------+---------+--------------------------------------------------------------+------+-------------+
| id | select_type | table                                   | type   | possible_keys                                                             | key                    | key_len | ref                                                          | rows | Extra       |
+----+-------------+-----------------------------------------+--------+---------------------------------------------------------------------------+------------------------+---------+--------------------------------------------------------------+------+-------------+
|  1 | SIMPLE      | node_comment_statistics                 | index  | PRIMARY                                                                   | node_comment_timestamp | 4       | NULL                                                         |   50 |             | 
|  1 | SIMPLE      | node                                    | eq_ref | PRIMARY,nid                                                               | PRIMARY                | 4       | issue_summaries_.node_comment_statistics.nid                 |    1 |             | 
|  1 | SIMPLE      | history_user                            | eq_ref | PRIMARY,nid                                                               | PRIMARY                | 8       | const,issue_summaries_.node.nid                              |    1 |             | 
|  1 | SIMPLE      | project_issues                          | eq_ref | PRIMARY,project_issues_pid,project_issues_sid,project_issues_nid_assigned | PRIMARY                | 4       | issue_summaries_.node.nid                                    |    1 | Using where | 
|  1 | SIMPLE      | node_project_issues_1__project_projects | eq_ref | PRIMARY                                                                   | PRIMARY                | 4       | issue_summaries_.project_issues.pid                          |    1 |             | 
|  1 | SIMPLE      | node_project_issues_1                   | eq_ref | PRIMARY,nid                                                               | PRIMARY                | 4       | issue_summaries_.node_project_issues_1__project_projects.nid |    1 | Using where | 
|  1 | SIMPLE      | users_project_issues                    | eq_ref | PRIMARY                                                                   | PRIMARY                | 4       | issue_summaries_.project_issues.assigned                     |    1 |             | 
+----+-------------+-----------------------------------------+--------+---------------------------------------------------------------------------+------------------------+---------+--------------------------------------------------------------+------+-------------+
7 rows in set (0.00 sec)

Here's the same view, sorted by create date ascending (oldest issues first) http://issue-summaries-drupal.redesign.devdrupal.org/project/issues?orde...

mysql> EXPLAIN SELECT node.nid AS nid,    node_project_issues_1.title AS node_project_issues_1_title,    node_project_issues_1.nid AS node_project_issues_1_nid,    node_project_issues_1__project_projects.uri AS node_project_issues_1__project_projects_uri,    node.title AS node_title,    history_user.timestamp AS history_user_timestamp,    node.created AS node_created,    node.changed AS node_changed,    project_issues.sid AS project_issues_sid,    project_issues.priority AS project_issues_priority,    project_issues.category AS project_issues_category,    node_comment_statistics.comment_count AS node_comment_statistics_comment_count,    node.type AS node_type,    node_comment_statistics.last_comment_timestamp AS node_comment_statistics_last_comment_timestamp,    users_project_issues.name AS users_project_issues_name,    users_project_issues.uid AS users_project_issues_uid,    'project_issue_all_projects:page_1' AS view_name  FROM node node   INNER JOIN project_issues project_issues ON node.nid = project_issues.nid  INNER JOIN users users_project_issues ON project_issues.assigned = users_project_issues.uid  LEFT JOIN node node_project_issues ON project_issues.rid = node_project_issues.nid  INNER JOIN node node_project_issues_1 ON project_issues.pid = node_project_issues_1.nid  INNER JOIN project_projects node_project_issues_1__project_projects ON node_project_issues_1.nid = node_project_issues_1__project_projects.nid  LEFT JOIN history history_user ON node.nid = history_user.nid AND history_user.uid = 1  INNER JOIN node_comment_statistics node_comment_statistics ON node.nid = node_comment_statistics.nid  WHERE (node.status <> 0 OR (node.uid = 1 AND 1 <> 0) OR 1 = 1) AND (project_issues.sid in ('1', '13', '8', '14', '15', '2', '4', '16'))    ORDER BY node_created ASC  LIMIT 0, 50;
+----+-------------+-----------------------------------------+--------+---------------------------------------------------------------------------+--------------+---------+--------------------------------------------------------------+------+-------------+
| id | select_type | table                                   | type   | possible_keys                                                             | key          | key_len | ref                                                          | rows | Extra       |
+----+-------------+-----------------------------------------+--------+---------------------------------------------------------------------------+--------------+---------+--------------------------------------------------------------+------+-------------+
|  1 | SIMPLE      | node                                    | index  | PRIMARY,nid                                                               | node_created | 4       | NULL                                                         |   50 |             | 
|  1 | SIMPLE      | history_user                            | eq_ref | PRIMARY,nid                                                               | PRIMARY      | 8       | const,issue_summaries_.node.nid                              |    1 |             | 
|  1 | SIMPLE      | node_comment_statistics                 | eq_ref | PRIMARY                                                                   | PRIMARY      | 4       | issue_summaries_.node.nid                                    |    1 |             | 
|  1 | SIMPLE      | project_issues                          | eq_ref | PRIMARY,project_issues_pid,project_issues_sid,project_issues_nid_assigned | PRIMARY      | 4       | issue_summaries_.node.nid                                    |    1 | Using where | 
|  1 | SIMPLE      | node_project_issues_1__project_projects | eq_ref | PRIMARY                                                                   | PRIMARY      | 4       | issue_summaries_.project_issues.pid                          |    1 |             | 
|  1 | SIMPLE      | node_project_issues_1                   | eq_ref | PRIMARY,nid                                                               | PRIMARY      | 4       | issue_summaries_.node_project_issues_1__project_projects.nid |    1 | Using where | 
|  1 | SIMPLE      | users_project_issues                    | eq_ref | PRIMARY                                                                   | PRIMARY      | 4       | issue_summaries_.project_issues.assigned                     |    1 |             | 
+----+-------------+-----------------------------------------+--------+---------------------------------------------------------------------------+--------------+---------+--------------------------------------------------------------+------+-------------+
7 rows in set (0.00 sec)

I don't immediately note a huge difference here.

I also enabled that Views statistics checkbox. First query:

Views plugins build time: 14.6639347076 ms
Views data build time: 19.9151039124 ms
Views handlers build time: 4.29010391235 ms

Second query:

Views plugins build time: 15.4590606689 ms
Views data build time: 19.8969841003 ms
Views handlers build time: 4.1229724884 ms

I don't think that those numbers are statistically significant, though, since I can reload 3 times and get 3 different answers.

Note that #19b is still an issue, but I figure I'll wait to get sign-off on this approach before spending an hour or two adding those hacks back in. In the meantime, this can be functionally reviewed at the URLs in #19.

I'd love to get yoroy or bojhan to comment here on their thoughts on this. I'm basically +1, but also aware that these pages are already a bit of info overload and I'm worried we're making a bad problem worse. However, I don't see this as a qualitative step backwards, and it does provide some useful info to certain groups that are worth prioritizing. Short of a major issue queue redesign, I'm not sure what else we can reasonably do to make this change and improve anything in the UX of the queues.

Re: 19.b: yeah, well, bleh back at you. ;) I'm not sure how else to handle this stuff. I *definitely* don't want to maintain N different versions of *all* of these views, but at the same time, some of the handlers are dependent on what modules you have enabled on your site. The custom logic in the default views seemed like the least evil choice, even though it makes things a bit trickier when you're re-exporting things. In my experience, it's generally easier to find the diff of what you changed and apply that to the existing exports, instead of trying to start from the new export and re-apply all the custom logic. YMMV.

Thanks,
-Derek

Yeah, that was a general bleh rather than a specific one. :) No problems, I'll take care of it. Thanks for the tip.

Spoke to Bojhan. He said the visual proximity of the updated/created fields causes visual stress and recommended moving them further away. Since I'm pretty sure people would expect Title, Status, Priority, Category, and Version to be grouped together, and since I'm also pretty sure people would expect "Assigned" to be on the right, I went with Created just before the Replies column.

Compare (old way): http://issue-summaries-drupal.redesign.devdrupal.org/project/issues/drup...
with (new way): http://issue-summaries-drupal.redesign.devdrupal.org/project/issues?orde...

Never mind, put the column on the right. See Bojhan's reply below.

It is a fairly common principle in table design not to put similar data next to each other, because this makes it harder to distinguish between the two. One would normally only do this when comparing is the primary use case (which from my perspective it isn't), for example stock market tables.

I suggested webchick to place it to the far right, to create a very clear visual distinction between the "last updated" and "created". It will have some effect to those used to assigned being on the right, but since it is a very distinctive visual element I don't see it causing any scan ability problems.

We do need to make a note here, that we are reaching the limits to where a table formatted like this is still usable.

What a beauty of an issue. A well-worded modest feature request hits community nerve. We get our queries AND design EXPLAINed. Community performance tweaks++

Yay, that's all great feedback -- much appreciated. I was thinking the same thing about the two date fields being right next to each other -- glad that wasn't just be being crazy/cranky. ;)

So, looks like we're just waiting for the re-roll based on #19.b. If that can happen soon (e.g. by Sunday or so), I'll push this before I disappear for a few weeks.

Thanks,
-Derek

YAY!! On it.

Here we go. I used dww's approach in #22 and it seems like that worked well (I love the views.php export method btw! :D). http://issue-summaries-drupal.redesign.devdrupal.org/project/issues/ is now running off of non-overridden views, straight from the filesystem.

Tested locally. Looked fine. I was a bit concerned about the hunk in project_issue.css but webchick clued me in on why that's needed (for issues with insanely long words in the title, e.g. issues that refer to function names and such). It's a bit ugly to hard-code 200px into our module-specific CSS file, but themers can override this if needed, and this is a problem that effects all themes, not just bluecheese. So, a hard-coded limit seems okay (even if unfortunate). ;)

Committed and pushed:

http://drupal.org/commitlog/commit/1894/7c85877d569abfd618db3be59b439791...

Just needs d.o deployment. Also, we already got the UX review, so removing that tag.

Thanks everyone!
-Derek

/ME DOES THE HAPPY DANCE!!!!!

THANK YOU DWW!!!!! :D

/me bows ;)

This will make us project application people very happy. Thank you.

It looks like this may have introduced a bug. Working in the project applications queue, I now have edit access to every issue, and posting a comment appears to create a new revision, or at least it increments the revision counter. I don't see how this could have caused that to happen. Maybe there was something else deployed at the same time?

Dang it. The "Created" column is in the wrong place on issues/user. (Next to "Last updated" rather than on the far right)

Not sure how I managed to do that.

Bleh! Sorry that took me so long to get to. Airport waiting FTW.

ran a quick local test and committed #38 -- looks good to me.

setting back to active for d.o deployment.

Awesome, thanks hunmonk! :D

Moving to RTBC, since I think Neil doesn't deploy things unless they're marked that way.

Looks like this still hasn't been deployed yet.

This was deployed when I pushed the follow button live.