Problem/Motivation
You can't show the autor of the current revision on views of type 'content' (those with a base table of 'node'). It is only possible to show this for 'revision' type views. This is very inconvenient. For example, if I want to add the autor of the current revision to the normal content view, I can't do this, unless I rebuild the entire view as a 'revision' based view.
Steps to reproduce:
- Create a single view of any content.
- Go to "add Relationships" and filter "user" text.
- At this screen you can't found this option that is needed:
User | Content revision | Relate a content revision to the user who created the revision.
(view screenshowts)
Before the patch image
After the patch image
Proposed resolution
Add Join to "Node revision" with "node field data"
Remaining tasks
- Needs review the proposed patch
- Needs written a test for this.
Original report by [Shabbir ]
Text of the original report:
I have created a normal view of type content and want to display my node fields along with other details such as node creation date, node last updated date and the author who has last updated the node.
I am able to achieve result of every other field but "last updated by user" is not displaying. What i am trying to do is, I created a relationship of content revision: user, and in my fields i added a field user: name with my " user" relationship added to the field. Still my view shows the field user: name as the content node author instead of the revision user.
In my table node_field_revision the uid remains the same as the author uid and does not change everytime a new revision is created by a different user. Is this normal?
Please let me know if you need more information on this.
Comment | File | Size | Author |
---|---|---|---|
#39 | 2769289.37-39.8_8_x.interdiff.txt | 547 bytes | dww |
#39 | 2769289.37-39.8_7_x.interdiff.txt | 842 bytes | dww |
#39 | 2769289-39.8_8_x.patch | 16.09 KB | dww |
#39 | 2769289-39.8_7_x.patch | 16.02 KB | dww |
#32 | 2769289-32.patch | 16.13 KB | idebr |
Comments
Comment #4
heikki CreditAttribution: heikki at Avoltus Oy commentedI 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.
Comment #6
benjifisherThere 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
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 onvid
, notnid
.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.
Comment #7
benjifisherMaybe 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.
Comment #8
benjifisherI 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.
Comment #11
Madis CreditAttribution: Madis at ADM Interactive commentedRolled 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.
Comment #12
Madis CreditAttribution: Madis as a volunteer and at ADM Interactive commentedManually tested on 8.7 dev and seems like everything still works with this patch.
Comment #13
benjifisher@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 thenode_revision
table. I think it should give theuid
field from thenode_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 thenode_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
Elsewhere in the same file, I see several sections that do something very similar for other tables, such as this:
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).Comment #14
benjifisherI just added #3012477: Clean up getViewsData() in NodeViewsData, as I mentioned in the last two paragraphs of #13.
Comment #15
brahmjeet789 CreditAttribution: brahmjeet789 as a volunteer and at gai Technologies Pvt Ltd commented@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 .
Comment #16
benjifisher@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.
Comment #18
di3gopa CreditAttribution: di3gopa for Rootstack commentedThis is still relevant i can confirm it works
Comment #19
fonant CreditAttribution: fonant commentedCan confirm that patch #11 solves the problem of not being able to display revision-creating user details.
Comment #20
aadeshvermaster@gmail.com CreditAttribution: aadeshvermaster@gmail.com commentedHi 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
Comment #21
vacho CreditAttribution: vacho at Skilld commentedComment #22
vacho CreditAttribution: vacho at Skilld commentedPatch rerolled.
Comment #23
vacho CreditAttribution: vacho at Skilld commentedComment #24
vacho CreditAttribution: vacho at Skilld commentedComment #25
asrobDoes 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:
Comment #26
vacho CreditAttribution: vacho at Skilld commentedHi @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.
Comment #27
jts86 CreditAttribution: jts86 at Four Kitchens commented#22 works for me
Comment #28
idebr CreditAttribution: idebr at ezCompany commentedAttached patch implements the following changes:
The user who created the revision.
for consistency with the other user id references.Comment #29
LendudeNice fix and test.
It seems to miss test coverage for this change.
Updated the title and IS a bit for clarity.
Comment #30
benjifisherComment #31
idebr CreditAttribution: idebr at ezCompany commented#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.
Comment #32
idebr CreditAttribution: idebr at iO commentedRemoved this relationship, as it is not necessary for this view.
Comment #33
Lendude@idebr thanks! Looks ready to me now.
Comment #34
aiphesI'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 ?
Comment #37
dwwFix 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
Comment #39
dwwWhoops! :)
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
.Comment #40
LendudeGreat work all, thanks! Looks ready to me now.
Comment #41
alexpottCrediting @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
Comment #44
alexpott@catch +1'd the backport.
Comment #47
aiphes@alexpott: is it ported ? in with drupal version ?
Comment #48
idebr CreditAttribution: idebr at iO commented#47 The code will be available in the next patch release for the 8.8.x branch (8.8.1) at the earliest.
Comment #49
aiphesok I will wait the next D8 release.
Comment #50
joshua.boltz CreditAttribution: joshua.boltz at Mediacurrent commentedIt looks like this is only for node revisions. What about other entities, like media and terms?
Comment #51
acbramley CreditAttribution: acbramley at PreviousNext commentedI need this for Media too, so have created #3113986: Can't show 'revision author' on Media views to track that.