Node revision UI will sometimes show no revisions on a page

This sounds similar to #2769741: Node revisions page might not list a default revision.

In that issue there was a lot of discussion around what the expected behaviour is. I think we need to fully nail down what that expected behaviour is, and clear it with the UX team, then work with a test driven approach to nail down the behaviour in a test.

Reroll for 8.6 since I just ran into this on an older site.

Attached patch for version 8.7.7

+1

Tagging for DrupalCamp Colorado's upcoming contrib day.

#17 successfully applied for me on 8.9.10 and solved the pagination issue for me. Our Drupal installation also has a lot of languages (30+) as described in the issue description.

Ignore this one.

Adding the same patch for 9.2.x.

All the above patches seem to break the work done in here:
https://www.drupal.org/project/drupal/issues/2938947
https://git.drupalcode.org/project/drupal/commit/41116a5

Which solved the issue that some revision lists would not have any "Current revision". This issue seems to be happening for me again now.
This might be because of this issue and the first patch was created earlier than the issue above.

All changes done in the NodeController.php in the patches above don't make any sense anymore and are not needed anymore. (tested this)
We can simplify the patch much more now, where we only have to change the query.

I will add a new patch where I revert all the changes in NodeController.php because they are not needed anymore.

I tested this new patch on 8.9.10 with 30+ languages and the pagination is working fine and it solves the "Current revision" issue (again) that I was having again.

I'm working currently on the https://www.drupal.org/project/drupal/issues/1863906 to see if I can fix there the issues, and I noticed that, it's not correct to use the `->condition($node->getEntityType()->getKey('revision_translation_affected'), '1')` condition, if you revert a translation to a previous version, then it won't be visible the current revision...

But it seems it works here properly, because of the custom conditions in the code regarding the latest version...
The #23 works fine, however @Falco010 can you remove the `if ($revision->hasTranslation($langcode) && $revision->getTranslation($langcode)->isRevisionTranslationAffected()) {` as it become useless.

Rerolling for 9.2.x

Reviewed whether the old patch still applies to the latest code and passes automated tests.

Steps taken to review:

Downloaded the latest patch file.

1. Used Git to clone local Git repository of 9.3.x of the development version that the issue pertains to.
2. The patch #27 applied successfully.
3. The automated tests for the project were re-run after I clicked the "retest" link in the patch file, the automated test passed successfully.

Result:

Verified the patch applied successfully, and the automated test passed successfully.

Changed to Need review for other test scenarios

+++ b/core/modules/node/src/Controller/NodeController.php
@@ -299,10 +299,13 @@ public function addPageTitle(NodeTypeInterface $node_type) {
+    $langcode = $node->language()->getId();

There's still some oddness going on here. If a specific translation doesn't exist and one visits the revisions tab, the langcode returned is for the default language, not the interface language. I think we should make that more obvious in the UI somehow. Maybe we need to list the language as the default instead? Alternatively, filter here by the interface language and show zero revisions.

Regarding #33, using the node language will be the correct language once the loaded node is correct for the interface language per #3092558: Revisions log on translated nodes should not show original language revisions, should show revisions of translated content

The Needs Review Queue Bot tested this issue.

While you are making the above changes, we recommend that you convert this patch to a merge request. Merge requests are preferred over patches. Be sure to hide the old patch files as well. (Converting an issue to a merge request without other contributions to the issue will not receive credit.)

By adding addMetaData('langcode', $langcode) we fix this issue and provide correct check by nodes grants

Issue summary appears incomplete, recommend using the standard issue template.

Also can a test case be added for this scenario to show the problem.

This is a duplicate of #2722307: Move translation based conditions into database query on revisions overview page I'll close this one as work has been started over there with a more fleshed out solution.

@acbramley I do not agree that #2722307 is a better solution. There the behavior has completely changed and not only the affected revisions are displayed.

With patch provided by @falco010 in #27, it is only filtering at the query level, but the same revisions are displayed as before, but we don't have empty pages anymore.

@romixua your suggestion did not work, I tried to apply the patch your provided in the MR, but I will have empty pages.

Hi @lisotton I understand where you're coming from but:
1. That issue also includes the langcode filter
2. There's no reason to have 2 issues open that touch the same code in similar ways. If we find in that issue that we don't want to remove the affected revisions check then we will remove it there, meaning it is exactly the same as this issue. Having both issues open is just splitting effort and making it confusing for contributors.

We should focus efforts on a single issue and since this one has the least recent activity and the MR is not up to date I think we should still close this one.

Please provide testing and feedback on #2722307: Move translation based conditions into database query on revisions overview page.