Users expect the "latest translation affected revision" not the "latest revision" in the views UI when moderating content

Would it be possible to get an export of the configuration of the view in question? It would also be helpful to see some of the relevant output from the content_moderation_state entity tables:

select * from content_moderation_state_field_revision;

Hi,
Maybe i can provide some details.
I have the same problem with this setup :
- Drupal core 8.6.1
- 2 languages enabled
- default workflow enabled for all content types.

The duplicate rows issue is solved by: https://www.drupal.org/project/drupal/issues/2977276

Remains this problem: the filter "Content revision: Is Latest Revision" filters the latest revision regardless the language.

ie :
- i have an original node in draft state, and i create a translated version in draft state -> the moderated content view only shows the translated version.
- I have an original node in draft state and a translated version in draft state, i publish the original node -> the moderated content view will display nothing because the latest revision for all multilingual versions is the published one.

I could reproduce this behavior on https://simplytest.me/ without any contrib module enable.

The filter "Content revision: Is Latest Revision" should filter the latest revision for each translated version.

Thanks for the additional information, that's really helpful. I'm going to try reproduce this.

I can confirm using the steps from #5, when creating a pending revision of a translation, the latest revision of the default language seems to revert to "published". State of the CMS entity table:

mysql> select revision_id as rid, langcode as lang, moderation_state as mod_state, content_entity_revision_id as content_revid, revision_translation_affected as rev_translation_affected from content_moderation_state_field_revision order by revision_id DESC limit 4;
+-----+------+-----------+---------------+--------------------------+
| rid | lang | mod_state | content_revid | rev_translation_affected |
+-----+------+-----------+---------------+--------------------------+
|   5 | en   | published |             5 |                     NULL |
|   5 | ca   | draft     |             5 |                        1 |
|   4 | en   | draft     |             4 |                        1 |
|   4 | ca   | published |             4 |                     NULL |
+-----+------+-----------+---------------+--------------------------+
4 rows in set (0.00 sec)

And the content view:

So this this is actually working exactly as intended, the latest 'en' revision in this case was "published". So I think we actually need a filter which replicates the logic that is in our entity converter:

  if ($entity instanceof RevisionableInterface && !empty($definition['load_latest_revision']) && $entity_definition->isRevisionable()) {
      // Retrieve the latest revision ID taking translations into account.
      $langcode = $this->languageManager()
        ->getCurrentLanguage(LanguageInterface::TYPE_CONTENT)
        ->getId();
      $entity = $this->getLatestTranslationAffectedRevision($entity, $langcode);
    }

We need a filter that loads the latest translation affected revision, not the latest revision unconditionally.

Fixing issue summary.

Some better wording of the root cause in the IS.

Here is a patch of the existing latest revision filter which works when combined with the other one. It'll need test coverage and to be moved into its own filter.

patch in #12 is solving the issue for me.
Thank you !

Here is the fix as a new filter with tests. Will still need an update hook and tests to replace the 'latest_revision' filter plugin with the 'latest_translation_affected_revision' plugin on the content moderation view.

Are you sure this needs to be a new filter? I think letting the use choose between a 'latest_revision' and a 'latest_translation_affected_revision' can get very confusing, so maybe it's easier to use the patch from #12 with an extra check on the entity type being translatable or not. And/or maybe make it configurable as well, with the behavior of checking the latest affected revision enabled by default, since that's most likely what the user would expect.

And/or maybe make it configurable as well, with the behavior of checking the latest affected revision enabled by default, since that's most likely what the user would expect.

This makes sense to me.

+++ b/core/modules/views/src/Plugin/views/filter/LatestTranslationAffectedRevisionTest.php
@@ -0,0 +1,116 @@
+class LatestTranslationAffectedRevisionTest extends FilterPluginBase implements ContainerFactoryPluginInterface {

This is not a test plugin this is an actual plugin so we should remove the suffix.

I tested path #14 and it works great! To get such a filter could also maybe be helpful for #2999938: Replace content translation table with a view

Thanks for the review!

I don't think it makes sense to change the behavior of the filter, given it's actually working correctly. I'm also not really a fan of making it configurable given it already feels quite complex. I'd rather they be split out so they can be documented, tested and iterated on in isolation. I think this is especially valid given the joins themselves are a candidate to be normalized into base tables in the future, having these as two seperate things may allow those to be unpicked easier down the line.

Okay, then let's go ahead with two filters :)

I think this is ready for a complete review. It includes:

• An integration test of the new filter replicating the conditions of the original bug report.
• Upgrade path and test for the moderated content view that ships with CM.
• The latest revision translation affected filter and tests from #14.

Fixing test name.

Patch #24 works in my case (documented in #3007456: Content Moderation State Field Revision with 2 Languages Set to Published). Thanks for a solution.

Reviewed the patch again and it looks great. Nice to have some manual testing as well, thanks @greggmarshall :)

Thanks for the manual testing and following up with another review.

Another +1 for this patch. We just came across the same issue as described by @greggmarshall in #3007456: Content Moderation State Field Revision with 2 Languages Set to Published which led us here. The new filter works as advertised :)

Fail was in HEAD, back to RTBC.

Referencing #3015312: The ModeratedNodeListBuilder does not show the correct revisions as it is responsible for achieving what the View is doing but via the list builder. They should go hand in hand.

This looks like potentially a real test failure:

Testing Drupal\Tests\content_moderation\Kernel\ModerationStateFieldItemListTest
....................F                                             21 / 21 (100%)

Time: 17.99 seconds, Memory: 4.00MB

There was 1 failure:

1) Drupal\Tests\content_moderation\Kernel\ModerationStateFieldItemListTest::testWithExistingUnmoderatedContent
Failed asserting that null matches expected 'published'.

/var/www/html/core/tests/Drupal/KernelTests/KernelTestBase.php:1121
/var/www/html/core/modules/content_moderation/tests/src/Kernel/ModerationStateFieldItemListTest.php:390

https://www.drupal.org/pift-ci-job/1115550

Hey @catch, thanks for reviewing. The failure in that test run was introduced in HEAD and then reverted, so I don't think we've got an intermittent fail in this issue.

Committed bd72409 and pushed to 8.7.x. Thanks!