In views 3.5 Title etc are not showing anymore

I can confirm this

I believe

SELECT node_node_revision.nid AS node_node_revision_nid, node_revision.log AS node_revision_log, node_node_revision.vid AS node_node_revision_vid, workbench_moderation_node_history.state AS workbench_moderation_node_history_state, workbench_moderation_node_history.nid AS workbench_moderation_node_history_nid, workbench_moderation_node_history.vid AS workbench_moderation_node_history_vid, workbench_moderation_node_history.current AS workbench_moderation_node_history_current, node_node_revision.title AS node_node_revision_title, node_node_revision.type AS node_node_revision_type, users_node_revision.name AS users_node_revision_name, users_node_revision.uid AS users_node_revision_uid, node_node_revision.changed AS node_node_revision_changed
FROM
{node_revision} node_revision
LEFT JOIN {users} users_node_revision ON node_revision.uid = users_node_revision.uid
LEFT JOIN {node} node_node_revision ON node_revision.vid = node_node_revision.vid
INNER JOIN {workbench_moderation_node_history} workbench_moderation_node_history ON node_revision.vid = workbench_moderation_node_history.vid
WHERE ((( (users_node_revision.uid = '1') )AND (workbench_moderation_node_history.current <> '0') ))
ORDER BY node_node_revision_changed DESC
LIMIT 25 OFFSET 0

should be

SELECT node_node_revision.nid AS node_node_revision_nid, node_revision.log AS node_revision_log, node_node_revision.vid AS node_node_revision_vid, workbench_moderation_node_history.state AS workbench_moderation_node_history_state, workbench_moderation_node_history.nid AS workbench_moderation_node_history_nid, workbench_moderation_node_history.vid AS workbench_moderation_node_history_vid, workbench_moderation_node_history.current AS workbench_moderation_node_history_current, node_node_revision.title AS node_node_revision_title, node_node_revision.type AS node_node_revision_type, users_node_revision.name AS users_node_revision_name, users_node_revision.uid AS users_node_revision_uid, node_node_revision.changed AS node_node_revision_changed
FROM
{node_revision} node_revision
LEFT JOIN {users} users_node_revision ON node_revision.uid = users_node_revision.uid
LEFT JOIN {node} node_node_revision ON node_revision.nid = node_node_revision.nid
INNER JOIN {workbench_moderation_node_history} workbench_moderation_node_history ON node_revision.vid = workbench_moderation_node_history.vid
WHERE ((( (users_node_revision.uid = '1') )AND (workbench_moderation_node_history.current <> '0') ))
ORDER BY node_node_revision_changed DESC
LIMIT 25 OFFSET 0

I believe this issue is related to #1361210: 'Workbench moderation: current' views filter does not list all content. Not all of it, but some of it.

Update: The Problem
Node table has the nid and vid field. Node Revision table has the nide and vid field.
Node table looks like

Node revision looks like

Notice node table is 5-6, not 5-7. This is because vid 7 is not published yet. If you publish vid 7 then the node table will be updated to 5-7.

If you do a join from node_revision to node on vid, it would return a NULL for title, type and update date. This is confirmed in Image attached to issue #1782172

Patch to follow...

This is a patch against 7.x-1.x. This applies cleanly against 7.x-1.2.

In this patch

• 2 new relationships
  • 1 for node
  • 1 for node revision (currently NOT using)
• Switch join on node table from inner to left
• Re-roll default view with all the updated relationships

The relationship to 'node revision' table might be removed as its probably be confused with 'node' table.

Re-rolled patch because of #1363990: The fields on the View workbench_moderation should use node_revision fields asking for the fields be from node_revision instead of the node table

This is a quite large patch. Has Views broken this intentionally or is this an open Views bug or really a workbench bug?

I have worked with workbench for only a months, so I probably do not know the whole picture. For the past year or so, the university I worked at has had problems with workbench & workbench moderation, everytime they upgraded views.

My Theories:
A - Views 3.5 tries to add a relationship when there isn't one.
B - Views 3.5 handles Content revision {node_revision} table differently.
C - May be a combination of A & B. Maybe views 3.3 handled Content revision table differently, then views 3.5 tried to fix this.

Possible views bug is explained in #4. You could possiblilty label this as a Drupal core bug.

Old default view had 2 fields:
nid_1 and title

#5 & #6 patch rename them to:
nid_1 and title_1

new patch renames fields to:
nid and title

With patch in #9 under url admin/workbench/needs-review I have two debug messages now:

Debug:
'Handler views_handler_field_node_revision tried to add additional_field language but node could not be added!'
in views_handler_field->add_additional_fields() (line 142 of sites\all\modules\views\handlers\views_handler_field.inc).
Debug:
'Handler workbench_access_handler_field_section tried to add additional_field nid but node could not be added!'
in views_handler_field->add_additional_fields() (line 142 of sites\all\modules\views\handlers\views_handler_field.inc).

Looks broken patch to me. Caches have been cleared.

Thanks for the update @hass. I had the same problem with my view, however I wasn't using the default view. I was using a custom view.

Attached are some screenshots with patch #9 applied to workbench 7.x-1.2

1. Debug message at admin/workbench/drafts
2. SQL error message on the views admin UI
3. View with broken relationship
4. View with fixed relationship

To go from #3 to #4 all I did was clicked on the field, then once the overlay loaded, clicked 'apply'. This worked because there was only 1 relationship called 'Node' to choose from.

If you are using the default view, you should not need to do this.

I'm not sure what you are trying to say me. We need to remove the debug messages and fix the incomplete/missing titles and section columns. Your patch does not solve this issues.

I know we need to remove the debug message and fix the view. My patch fixes (or suppose to fix) the default view for workbench_moderation. If you have overridden the view then you will have to fix the view yourself. #11 outlines how to do that.

If you are using a default view and this patch does not fix your view, you need to double-check 2 things:

1. Goto Admin -> Structure -> Views. Find the Click the down arrow beside 'edit'. If you see 'revert', then you have overridden view and need to revert or change the view manually.
2. If you don't see the 'revert', then click 'edit' to take you to the view edit screen. Do you see a 'Save' and 'Cancel' button? If so, click save or cancel, then check #1 again.

After doing the above, and it is still not fixed, then please report.

I'm using the default. It is not overridden.

Ok, I'm a little stumped then. Can you use the patch version of 7.x-3.5 view, override the default, and make it work by using the Workbench Moderation: Node relationship instead of Content Revision: Content. (and change Nid, Title & Type, Updated Date to use this new relationship)

I'm currently not able to do any tests or look into the code, but have you tried downgrading Views? Or have you compared the views_handler_field.inc from Views 3.3 and 3.5 what have been changed? I just applied your patch and done 2 minutes testing and nothing more. The debug message is from Views and we just need to find out why this adding fails. Maybe it's a views bug... but I'm still only guessing.

I'll explain a little more

#4 explains why Content: Type will never work. This is a core bug.

workbench moderation view uses {node_revision} as a base table. It has fields of Content: Nid, Content: Title, Content: Updated Date, Content: Type as well as others. Views has a group of fields that you can add. They are Content revision: vid, Content revision: Updated date, Content revision: Title

In Views 3.5, views tries to help itself by adding a relationship Content revision: Node. This is what is breaking everything.

If you change all of the fields from Content: X to Content revision: X, then views does not try to add the new relationship.

There is one problem, there is no Content revision: Type as there is not {node_revision.type} field in the database, only a {node.type} field.

I have created a new relationship which is inside the patch called Workbench Moderation: Node If you create a new field Content: Type and use the new relationship, the Content type will be displayed. This works because the relationship is {workbench_moderation_history.nid} to {node.nid}, where the other relationship is {node_revision.vid} to {node.vid}

I am using the patch from #9. The issue I am having is that if I create a new node and put it into the needs review state and then go to admin/workbench/needs-review and click on the title I get an access denied even though I am logged in as an admin. Is anyone else experiencing this?

You do not have the 'View content revisions' permission.

Before the title was link to the original content. I am using the Content Revision: title field not instead of Content: Title. We now have 2 options

Should it be a link to node/%nid or node/%nid/revision/%vid/view. I have open a new issue to discuss this: #1789296: Should the title be link to the original node or the revision?

@briand44 other than that, did the patch work for you?

I do have the view content revisions permission.

It only seems to be an issue when there is no published revision of the node.

I haven't found any other issues so far.

In Views 3.5, views tries to help itself by adding a relationship Content revision: Node. This is what is breaking everything.

this means views need to be fixed...?

@hass #21, I'm leaning towards no. I think when workbench_moderation-7.x-1.0 came out, views was broken. It didn't know how to handle content revision views properly. Workbench Moderation created a view that would work with Views at the time. Views 3.5 is no longer broken. It realizes it pass mistakes, and tries to create a relationship.

IMO, What should happen with Views:

You create a Content revision view ({node_revision} is the default table instead of the {node}). The only fields available to you are Content Revision: X. If you add the relationship Content Revision: Content, then you will be able to uses additional fields, Content: X.

What views 3.3 and Workbench Moderation 7.x-1.2 does:
Content revision view, Uses Content: X fields, with no relationship

I have looked at how Workbench module creates it views and I do not understand how they have manage to make their views work. There is an extra field that uses aggregation. COUNT(Content revision: Vid). This extra field adds multiple GROUP BY X,Y,Z to the sql query. If you remove this field, the views breaks.

If any SQL experts can share their insight, on how this field fixes everything for them, that would be great.

Duplicate of the cases #1781744: Draft and Needs review pages are broken and #1792144: "My Edits" View is broken that seems to have well working patches.

current patches are not working for #1781744. They ignored the problems identify in this issue queue
patch #1792144 should work as it is for workbench not workbench_moderation.

I might reopen this issue, however I will not do it yet.

@iStryker

It looks like you uploaded a patch in comment 28 of #1781744: Draft and Needs review pages are broken that looks like it should be added to this issue instead, or am I reading #1781744 incorrectly?

Since #1781744: Draft and Needs review pages are broken seems like an entirely separate problem (fixed in Workbench Access), I suggest we actually update the moderation view to use the correct relationships/fields/filters.

There are two cases with the same issue / title. One in workbench moderation and one in workbench queue. May be confusing... You need both, see #24 for both links.

Right, but "title", "type", etc. are not showing up because the relationship "fixed" by Views joins on the "vid" column from revision to node, when in fact revisions in "Needs Review" state do not reference the node's default "vid". Thus, any field on the joined node table is NULL.

From Views 7.x-3.5+6-dev onward, there is now an extra relationship for joining on "nid". I'm using this new relationship to make my moderation view to display exactly the correct columns (without any error message).

So, should I still post my version of the fixed view?

There is a views join bug and the patches already fix the issues. Please check the cases and review them, or rtbc them...

I have tried numerous patches after attempting to follow these threads. I'm not sure if it was a combination of all patches, but when I applied: workbench_moderation-1792144-27-do-not-test.patch on comment #27 here: http://drupal.org/node/1792144 my node titles and content types came back in the My Drafts tab, and Needs Review tab.