Can't show 'revision author' on views of type 'Content'

I ran into the same issue myself.
The correct last uid for user that has last updated is only present in "node_revision" table, but the "node_field_revision" always has the uid of the original author. Is it supposed to be?
If so, how can we use the "node_revision" table in views? I wasn't able to join it through any relationship.

There does not seem to be a relationship to connect a node (or other entity) to its current revision. Maybe there is already an issue for that.

What you can do is

1. Create a view of node revisions.
2. Add a relation to Content (the second one)
3. Check the box for "Require this relation".
4. Give it an administrative title, such as "Content" (recommended).

It is odd that there are two relations you can add that are both labeled "Content". If you inspect the SQL query (See /admin/structure/views/settings/advanced.) then the one you want creates a join on vid, not nid.

This will give you one row of results for each node, and you have access to both the node table and the node-revisions table.

This will not solve all problems. For example, if your view involves two nodes connected by an entity reference, and you want to access revision authors of both nodes, then this will not work.

Maybe this only works for nodes and custom blocks. If I read #2652652: Provide a relationship from the revision table to the main table correctly, the relation I described is not available for all entities.

I am adding #2932880: Two relations from content revisions to content look identical as a related issue. That fixes the problem of distinguishing between the two relationships I mentioned in #6 above.

Rolled a patch for 8.6.0-rc1. With this applied and caches cleared you should be able to add a "User" relationship with the "Relate a content revision to the user who created the revision." description to get the revision author.

Manually tested on 8.7 dev and seems like everything still works with this patch.

@Madis:

Thanks for working on this. I think this issue comes up a lot, and it is something that should "just work" but does not.

I think we should update the issue summary, using the issue summary template and adding information from the comments so far (related issues, work-around, and so on). I am adding the Novice task because the summary update is a suitable task, even though fixing the issue is not.

There are a few things I do not like about the solution in #11. The most important is that it is limited, just letting us add a relation to the revision author (node -> author of current revision). I think it would be more useful to add a relation to the current revision (node -> current revision). Then we could access the other information related to the revision, such as the changed timestamp, and get a two-step relation to access the revision user (node -> current revision -> author).

Alternatively, there is already a field we can add to the view: "Authored by" in the "Content revision" category. In my testing, this always gives the same thing as "Authored by" in the "Content" category. Unless I am missing something, this is just broken, and we should fix it instead of adding new options.

A second problem is that the patch in #11 seems to give the revision_uid field from the node_revision table. I think it should give the uid field from the node_field_revision table instead. Maybe that is the desired behavior, but I am not sure. (It is certainly consistent with Comment #4.)

Here is what that means in practice. Logged in as admin (uid = 1) I create users alice (uid = 2) and bob (uid = 3). I create two nodes, with two revisions each, and (still logged in as admin) I edit the "Authored by" field (in the "Authoring information" fieldset) so that alice and bob each are listed as the author of one node, and each is the author of the second revision of the other's node. When I follow the instructions in #11 (add a relation, add a field based on that relation) I get "admin" for both nodes. Looking at the database, I see that all four revisions have revision_uid = 1 in the node_revision table.

I know that editing the "Authored by" field is unusual, but if we are going to patch core, then we have to get it right. Also, we already have other work-arounds, like the one I described in #6.

Next objection: a change like this needs some automated tests before it can get into Drupal core.

I wonder how well this works with content moderation, when the current revision is not always the latest revision.

Finally, looking at the code, the patch has

+    $data['node_revision']['table']['join']['node_field_data']['left_field'] = 'vid';
+    $data['node_revision']['table']['join']['node_field_data']['field'] = 'vid';

Elsewhere in the same file, I see several sections that do something very similar for other tables, such as this:

    // For other base tables, explain how we join.
    $data['node_access']['table']['join'] = [
      'node_field_data' => [
        'left_field' => 'nid',
        'field' => 'nid',
      ],
    ];

When we are doing the same thing in the same function in the same file, I think we should do it the same way. We might also want to add the new lines near the lines I quoted.

Going back to a more general point of view, I am disappointed by the code quality in the existing file, NodeViewsData.php. This is in the Node module, so it should be a model for others to follow, and it should be well documented. Instead, it is badly organized and poorly commented. Cleaning it up is certainly out of scope for this issue, but I may add a new issue to do something about it.

Technical note: the NodeViewsData class extends EntityViewsData and implements one method. The relevant interface is EntityViewsDataInterface, and all it says about getViewsData() is @return array ... Views data in the format of hook_views_data(). So the actual documentation of the method is hook_views_data() (in views.api.php).

I just added #3012477: Clean up getViewsData() in NodeViewsData, as I mentioned in the last two paragraphs of #13.

@Madis your #11 patch working fine for me i can see relationship field after applying your patch in my view, i have already added screen shot fr the same , please check @benjifisher i have same requirement in my project and i apply the patch please correct me if i am wrong .

@brahmjeet789:

Thanks for adding the screenshots. That will be helpful when updating the issue summary. Before we ask one of the core committers to look at this issue, we should do them the favor of making the issue as easy to review as possible. Using the issue summary template and adding your screenshots will be helpful.

Testing is also required, not just "nice to have". It is the fifth requirement listed on Drupal core gates. I should have added the appropriate tag along with my Comment #13. I will do that now.

The issue summary update is also part of one of the other gates, Documentation.

Your testing shows that the current patch is useful, but that does not mean that it is ready to be added to Drupal core. If you want to help move the patch along, then updating the issue summary will do a lot more than changing the status to RTBC.

This is still relevant i can confirm it works

Can confirm that patch #11 solves the problem of not being able to display revision-creating user details.

Hi All,

I have checked this patch #11 & found 1 issue, if a content has already published & then someone do some changes and save in draft mode then Last Modified user is not updating. Its still show the last published user name.

Thanks

Patch rerolled.

Does not work when there is another language than English or translation enabled(?).

When I use the English language, it works well, but in Hungarian it does not. I got this:

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'revision_uid' in 'on clause': SELECT COUNT(*) AS expression FROM (SELECT 1 AS expression FROM {node_field_data} node_field_data INNER JOIN {users_field_data} users_field_data_node_field_data ON node_field_data.uid = users_field_data_node_field_data.uid LEFT JOIN {users_field_data} users_field_data_node_revision ON revision_uid = users_field_data_node_revision.uid WHERE (node_field_data.status = 1 OR (node_field_data.uid = 1 AND 1 <> 0 AND 1 = 1) OR 1 = 1)) subquery; Array ( )

Hi @asrob, thanks for your feedback.

I try to reproduce the issue that you report and I can't. I add the Hungarian language, Spanish language, and the patch works fine. Are you sure that you work over 8.8.x branch?

See this screen capture.

#22 works for me

Attached patch implements the following changes:

1. Added test coverage for the node_revision:revision_uid field
2. Updated the Views label to The user who created the revision. for consistency with the other user id references.

Nice fix and test.

+++ b/core/modules/node/src/NodeViewsData.php
@@ -243,8 +243,13 @@ public function getViewsData() {
+    $data['node_revision']['revision_uid']['filter']['id'] = 'user_name';

It seems to miss test coverage for this change.

Updated the title and IS a bit for clarity.

#29 Added an assertion for filtering by revision_uid. The test now includes the nid, vid, uid and revision_uid to make it a bit easier to scan.

+++ b/core/modules/node/tests/modules/node_test_views/test_views/views.view.test_node_revision_uid.yml
@@ -308,7 +373,18 @@ display:
-      relationships: {  }
+      relationships:
+        revision_uid:
+          id: revision_uid
+          table: node_revision
+          field: revision_uid
+          relationship: none
+          group_type: group
+          admin_label: 'revision user'
+          required: false
+          entity_type: node
+          entity_field: revision_uid
+          plugin_id: standard

Removed this relationship, as it is not necessary for this view.

@idebr thanks! Looks ready to me now.

I'm looking for this feature for my content view, and I see it will be available for D8.8, possible to have it on D8.7 ?

Fix the trivial CS problem the bot is complaining about.

I did a close review:
- Code is simple and clean.
- Test coverage is solid, well-written, and complete.

Also tested this on a real site (8.7.8) and it's working beautifully.

Back to RTBC.

Thanks!
-Derek

Whoops! :)

We now need separate patches for 8.7.x vs 8.8.x and up:

8.8.x now includes these:
#3087692: Remove the core key from views configuration.
#1886018: Make it possible to configure exposed filter operators

So, the 8.7.x patch needs to leave the core key that was in the default view, but remove the settings for the limited exposed operations.
The 8.8.x patch can use the limited exposed operation settings, but needs to remove core.

Great work all, thanks! Looks ready to me now.

Crediting @Lendude, @benjifisher for patch review and issue management
Crediting @Shabbir for filing the issue.

Committed and pushed a7984df264 to 9.0.x and 921bc08514 to 8.9.x. Thanks!

Will ask other committers for a +1 for backport to 8.8.x

@catch +1'd the backport.

@alexpott: is it ported ? in with drupal version ?

#47 The code will be available in the next patch release for the 8.8.x branch (8.8.1) at the earliest.

ok I will wait the next D8 release.

It looks like this is only for node revisions. What about other entities, like media and terms?

I need this for Media too, so have created #3113986: Can't show 'revision author' on Media views to track that.