Provide a way for users to moderate content

How about adding a secondary tab to the content page just like comments page instead of a new primary tab? I believe we add a primary tab for media as well. We'll end up having too many primary tabs.

I think postponing this is misleading, yes it depend on #2862041: Provide useful Views filters for Content Moderation State fields but needs a lot of work if we're going to get Content Moderation stable this week.

I've been looking at options here, and it doesn't seem we can alter the views.view.content view shipped with Node module, so we'd have to provide our own. Do we provide one for Node and Block? What about Media?

Do we provide one view at "/admin/content/moderated" and one view at "/admin/structure/block/block-content/moderated"? Would they be the same as the default views, just with the added "Moderation state" exposed filter?

Any chance we can leverage optional fields/filters as we do with language in the content overview? The language column and filter are hidden until the Language module is enabled. I don't remember the technical details though, so I'm not sure it's feasible for CM.

I think we should create new view under admin/content/node something like admin/content/node/moderate and we can make it a secondry tab. That way we can add it to any list builder without cluttering the admin menu.

Anyway, regardless of the route we choose, separate view or content or view, Angie mentioned content so we should stick to nodes, I'd say.

The commit freeze for 8.4.0-beta1 is this morning, so there should not be any additional feature additions this week (or to 8.4.x at all).

Edit: I can see how it is important. But we should not operate under the assumption that we're going to rush and not sleep for 72h and land a new view for a user page, or delay the beta.

WRT the above about nodes, yes, I'd recommend restricting the scope to a node view to start as I think that's probably what users will expect as the 80% usecase. Other additional moderatable things could be feature additions in later releases, if desired.

This is really a minor-only change, which currently means 8.5.x, so setting accordingly. Also setting to active since there's no patch. Maybe we would backport it if it's the only thing at all blocking content moderation from being stable, if the product team thinks it can't be stable without this at all, but we would make that decision after commit. (However, if it's a must-have, getting it into 8.5.x at least is what we ant regardless.

This is still technically postponed on #2862041: Provide useful Views filters for Content Moderation State fields but I don't want to put off people working on it, and we don't have a "Postponed (active)" or "Postponed (Needs work)" status.

It would be devastating to not see Content Moderation and Workflows stable in 8.4.0 because of this issue.

It would be devastating to not see Content Moderation and Workflows stable in 8.4.0 because of this issue.

@timmillwood, I'm concerned by this statement. The requirement for both modules is that they be beta, which they already are. There's no risk there. It would be cool for them to be stable, but since that's only something we started considering in the past week, why would it be devastating for them to not be?

But the initial feature deadline for 8.4.x is already two weeks ago and this issue did not even exist then. We used to burn people out around the beta by constantly delaying and delaying and adding all kinds of exceptions for issues that might never be done, and it was bad, and we don't do that anymore on purpose. Beta is supposed to be a hard deadline across the board to be fair to everyone.

However, it also should not matter I hope in terms of the feature itself. If the view needs to be added, then it will need to be committed to the minor development branch (currently 8.5.x) at some point.

TLDR, I think it's worth focusing on regardless, but the deadline has already passed for the beta so don't stay up nights or anything. My recommendation is to work on the feature and let committers sort it out after commit.

Also note that Workflows can be stable regardless as far as I understand since this view would be added to Content Moderation. So even if the product team thinks we can't mark Content Moderation stable without this, Workflows is not affected.

I believe Workflows is waiting on #2899553: Architectural review of the Workflows module (documentation cleanups) and then yes, we can get #2897130: Mark workflows module as stable in to make Workflows stable.

We have been working for months under the impression we were working towards Content Moderation being stable in 8.4.x because it would've been experimental for 1 year. It seems like such a tough blow to not make it stable after such a focussed effort from many many people. This also allows us to move on to other aspects in the initiative such as Workspaces.

It sounds like #8 is a good approach, I am working on a patch for this now.

Thanks @timmillwood.

We have been working for months under the impression we were working towards Content Moderation being stable in 8.4.x because it would've been experimental for 1 year. It seems like such a tough blow to not make it stable after such a focussed effort from many many people. This also allows us to move on to other aspects in the initiative such as Workspaces.

Once it's done, it's done, regardless of which branch it's done in. It could still be marked stable in 8.5.x as of Friday. I am not sure how it could have the impression for months; you and I discussed it back around 8.3.0 and agreed that it needed to be beta by this release. I made this change to the roadmap at your request: #2755073-74: WI: Content Moderation module roadmap

Looking at Angie's screenshot, I'm wondering if this actually something where we should be changing the default core admin/content view itself (adding a filter) after Content Moderation is stable and as part of providing it in Standard. Perhaps overriding the route or such. "As an administrator, I expect to be able to list content in all moderation states as part of a single administration screen." Having a different tab I need to look at to see a subset of some nodes seems like bad UX, especially since it will be the same-but-different view it is at admin/content.

We can't change admin/content before Content Moderation is stable though. Adding a default view itself is trivial, but once we add it as part of a stable release, at least some sites are stuck with it because after installation, it's the site's config and not CM's. The site owner can choose to configure the view differently, so we cannot overwrite it or change it once installed. We could only change it for sites that install it later.

So, I'd encourage us to not rush this issue just because we want to meet a deadline (that has already passed), and compromise on the correct user experience.

(In this respect, it's more or less a "critical bug" with Content Moderation, and IMO should qualify for backport.)

Well, even with bugs, if the change introduces disruption or breaks semver, we only add it in a minor release generally, even sometimes for criticals if we think it's actually disruptive: https://www.drupal.org/core/d8-allowed-changes#minor However, I can see how we should categorize this as a bug, so marking it as such.

This isn't a "feature"... this is a gaping hole in the basic functionality, it was identified back in June 2016, and it was supposed to block initial commit of the Workflow functionality in the first place.

I am super confused; this seems like a brand new issue? But it sounds like maybe we just had misunderstanding between the product review and the initiative on what the scope of #2862041: Provide useful Views filters for Content Moderation State fields was.

@webchick, do you think that moving from sub-tabs to a filter on the view itself would be a blocker for adding it to Standard?

Hmm actually, I just remembered again why I think the tab pattern does not work. admin/content already has the "Published" and "Unpublished" bulk operation selector. Putting "Draft" on a different page seems to me like it would be extremely confusing.

Once it's done, it's done, regardless of which branch it's done in.

Yes, it'll be stable, but not stable in a stable release.

I am not sure how it could have the impression for months; you and I discussed it back around 8.3.0 and agreed that it needed to be beta by this release.

Since March there has been a number of discussion it was stated (or maybe just implied) about working toward getting them stable in 8.4.0. Not as a requirement, but as a goal.

the simplest thing that can possibly work is @jibran's suggestion of replicating a similar pattern we have for comments

Here's a patch which does that.

This update removes the status column from the table, because that doesn't make sense. It also adds a "Moderation state" column and "workflow" columns, both of these are sortable, and the workflow name links to the workflow.

The patch in #23 and #24 adds a hard dependency on Views, so either we add that dependency to content_moderation.info.yml, or we create a fallback.

Unassigning from me for now.

It looks as though the failing test is due to the views dependency.

This patch drops the workflow column, moves the moderation state select list, updates the sub tab title, and adds a views dependency.

#30.1 - Sub-tab not appearing on "content" view still to do.

Note: This patch is a combined patch with #2862041: Provide useful Views filters for Content Moderation State fields.

Minor: would it make sense to rename the main tab from Content to Overview (or whatever we use in these cases). Otherwise we have two stacked "Content" tabs, which is not great.

patch #31 failed at some point on last 8.5 build:

patching file core/modules/content_moderation/config/optional/views.view.moderated_content.yml
patching file core/modules/content_moderation/config/schema/content_moderation.schema.yml
patching file core/modules/content_moderation/content_moderation.info.yml
Hunk #1 FAILED at 7.
1 out of 1 hunk FAILED -- saving rejects to file core/modules/content_moderation/content_moderation.info.yml.rej
patching file core/modules/content_moderation/content_moderation.links.task.yml
patching file core/modules/content_moderation/src/Plugin/views/filter/ModerationStateFilter.php
patching file core/modules/content_moderation/src/ViewsData.php
patching file core/modules/content_moderation/tests/modules/content_moderation_test_views/config/install/views.view.test_content_moderation_state_filter.yml
patching file core/modules/content_moderation/tests/modules/content_moderation_test_views/config/install/views.view.test_content_moderation_state_filter_entity_test.yml
patching file core/modules/content_moderation/tests/modules/content_moderation_test_views/config/install/views.view.test_content_moderation_state_filter_revision_table.yml
patching file core/modules/content_moderation/tests/modules/content_moderation_test_views/content_moderation_test_views.info.yml
Hunk #1 FAILED at 8.
1 out of 1 hunk FAILED -- saving rejects to file core/modules/content_moderation/tests/modules/content_moderation_test_views/content_moderation_test_views.info.yml.rej
patching file core/modules/content_moderation/tests/src/Kernel/ViewsModerationStateFilterTest.php
patching file core/modules/system/tests/modules/entity_test/src/Entity/EntityTestNoBundle.php

2. (hard-blocker) Either add the hard dependency to Views or add a manual controller type as a fallback. (The thinking on the call was just to add the hard dependency for now and look to remove it possibly in a later release, but this is something that needs buy-in from the Content Moderation maintainers.)

I wasn't quick enough to reply on the UX call when you asked me but I'm not buying the hard dependency on VIews at all :) So here's a patch that adds a manual fallback controller, whose implementation is really simple: just use the node view builder (which is also used as the default content list fallback) and switch the 'Status' column to a 'Moderation state' one. Of course, we have to do a bit more than that, like loading the latest revisions of the nodes instead of the default ones, but it's still fairly simple and good enough for a fallback, IMO.

This fallback controller also has a nice side effect that it fixes hard-blocker 1, the problem that was preventing the sub-tab from appearing on the Content view.

Here's how it looks:

And the main content overview tab:

And it seems that I forgot why I wrote the patch above.. so we can remove the dependency :/

After writing the fallback controller I noticed that its output was different than the one from the view, because the view was showing the title of the default revision instead of the latest one.

So.. hey, I just need to add the 'Is Latest Revision' filter provided by Content Moderation, right? Nope! Turns out that the moderated_content view was not even using revisions at all :(

I rebuilt the view starting from scratch and, sadly enough, we're now dealing with a whole new set of problems:

1. The content type filter/field is not available from the revision tables (no idea why!) so I had to create a relationship to the base tables in order to get it, and.. surprise: it's not showing anything for a node with a pending revision

2. The moderation state field: my content (two articles and a page) was created before enabling the Content Moderation module, and, after enabling it, I only edited one of the articles and created a draft revision for it (Test article 1 - draft). This means that I have no ContentModerationState entry for the article that was not updated (Test article 2), so it doesn't have any state. #2867312: Create a batch process to ensure entities that exist for newly moderated entity types get a corresponding ContentModerationState entity, so that views works. is still open..

3. The 'Operation links' handler also needs to use the relationship to the base tables, and, unlike the content type case above, it's completely broken and the view is blowing up because of some fatal error. The upside is that this one is most likely the easiest to fix :)

With a fair bit of sadness, here's our moderated node revisions view:

I also stumbled upon the initial issue that was opened to tackle this problem #2780613: Ensure that content in moderation can be found in the admin UI easily

This patch fixes #37.1 and #37.3.

I changed the relationship in the view to join on entity ID rather than revision ID, and I added a "content revision" version of the operations field to EntityViewsData.

Here's a screenshot to prove it with a list of draft (default revision), published, and draft (pending revision) articles.

The fix for #37.2 might be #2852067: Add support for rendering computed fields to the "field" views field handler, then we won't need the ContentModerationState relationship.

#37.2 is a particularly tricky issue, and we have two options.

1. Keep the functionality as it is now, moderated entities only show up if they are saved after moderation is enabled.
2. Show all entities, even if they aren't moderated, the moderation column would be empty of have a value such as "Not moderated".

Content Moderation stores the moderation state in the ContentModerationState entity. These only get generated when an entity is saved after Content Moderation is installed and after moderation is enabled on the entity type. We compute an initial value of the moderation state based on the publishing status, this can be used with #2852067: Add support for rendering computed fields to the "field" views field handler to list the moderation state for an entity before moderation is enabled, but the filtering works by an SQL join to the ContentModerationState entity tables, so filtering to show entities with no moderation state will not display the ones created before moderation is enabled, because there the state is computed and can not be queried.

#39 failed to be applyed on 8.5

...
patching file core/modules/content_moderation/tests/modules/content_moderation_test_views/content_moderation_test_views.info.yml
Hunk #1 FAILED at 8.
...

this leads to an error when going to content page:

ymfony\Component\Routing\Exception\RouteNotFoundException: Route "content_moderation.admin_moderated_content" does not exist. in Drupal\Core\Routing\RouteProvider->getRouteByName() (line 190 of core/lib/Drupal/Core/Routing/RouteProvider.php). 
Drupal\Core\Menu\LocalTaskDefault->getRouteParameters(Object) (Line: 310)
Drupal\Core\Menu\LocalTaskManager->getTasksBuild('system.admin_content', Object) (Line: 358)
Drupal\Core\Menu\LocalTaskManager->getLocalTasks('system.admin_content', 0) (Line: 94)
Drupal\Core\Menu\Plugin\Block\LocalTasksBlock->build() (Line: 203)
Drupal\block\BlockViewBuilder::preRender(Array)
call_user_func('Drupal\block\BlockViewBuilder::preRender', Array) (Line: 376)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 448)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array) (Line: 490)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 47)
__TwigTemplate_f8a17f041581af9829850fd45db45c2b69d8b3a60b80408d416da5d23dbccb61->doDisplay(Array, Array) (Line: 432)
Twig_Template->displayWithErrorHandling(Array, Array) (Line: 403)
Twig_Template->display(Array) (Line: 411)
Twig_Template->render(Array) (Line: 64)
twig_render_template('core/themes/seven/templates/page.html.twig', Array) (Line: 384)
Drupal\Core\Theme\ThemeManager->render('page', Array) (Line: 435)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array) (Line: 490)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 90)
__TwigTemplate_be8c7bbb9c824f2826368d7c8da984c6279779db72a67fd8056a00bb23b816f2->doDisplay(Array, Array) (Line: 432)
Twig_Template->displayWithErrorHandling(Array, Array) (Line: 403)
Twig_Template->display(Array) (Line: 411)
Twig_Template->render(Array) (Line: 64)
twig_render_template('core/themes/classy/templates/layout/html.html.twig', Array) (Line: 384)
Drupal\Core\Theme\ThemeManager->render('html', Array) (Line: 435)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array) (Line: 147)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 574)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 148)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object) (Line: 108)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.view', Object) (Line: 158)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 656)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

But more important, as already stated in "https://www.drupal.org/node/2862041#comment-12223325" when I try to add the moderation state field in a view, I got the following error:
The handler for this item is broken or missing.

Step to reproduce: (drupal 8.5)
1-edit content view
2-add the "moderation state" field from the "content" category (same problem with the revision category)
3-the error is popping up

@DuneBL - the moderation state needs to be added with a relationship to ContentModerationState until #2852067: Add support for rendering computed fields to the "field" views field handler lands.

Re #43: I can't replicate the issue on 8.5.x

Many thanks for checking...
I could remove the #43 problem after a drush cr (the devel flush cache button was not enough ?!?)
=>Sorry for having loosing your time.... maybe we should run something to apply the updated config file (ex: routing)?

regarding #45, I have added a relationship to ContentModerationState, but the problem stay... Anyway, I will wait the landing!

@timmillwood:

Here's a screenshot to prove it with a list of draft (default revision), published, and draft (pending revision) articles.

This explanation makes me think that maybe we need the status column after all, otherwise how would a user know whether a node is actually visibile on the site in some form or not?

@DuneBL, re #44: we have a dedicated issue for that: #2859381: Broken/missing handler for Moderation state field

If I've rolled these patches correctly the combined one includes patches from #2862041: Provide useful Views filters for Content Moderation State fields and #2852067: Add support for rendering computed fields to the "field" views field handler, where as the standard patch is just the bits this issue is adding, and the interdiff is the changes from #39.

Here I have:

• Removed the relationship between ContentModerationState.
• Linked the entity title to the entity.
• changed the path from "moderate" to "moderated".
• Added a filter to not show entities with no moderation state.

Updated screenshot:

Note: This still doesn't "fix" #37.2, nodes created before moderation is enabled will not show in the "Moderated content" view. If we remove the filter to not show entities with no moderation state it will show nodes created before moderation was enabled, but it will also show nodes without moderation enabled where the moderation state will be empty.

We could throw a warning in a DSM to say "Content added before moderation was enabled are not listed", this was an idea that came up when talking to @jojototh and @dixon_.

Another option I've been looking into is using COALESCE() to compute the moderation state if it doesn't exist. See #2862041-86: Provide useful Views filters for Content Moderation State fields.

Even after my comments in #51 and #52, I'd be extremely happy for #50 to be committed, I just want to make sure all options were looked into.

Just had a call with @webchick, she seemed happy with the patch from #50 but two changed need to happen:

• Update the view to not show content in the "Published" state.
• Update the empty text to explain clearer why there is no moderated content.

I'm happy to see 8.4 may becomes the first useable D8 release if moderation is stable, but "Content added before moderation was enabled are not listed" sound not really funny... that is like data loss. Why not running a migration of current content so it get's listed? How should people find their content otherwise?

@hass - you'll find it exactly where it was before you enabled moderation.

@hass - ALL content will still show up at Content > Overview; MODERATED content only will show up at Content > Moderated content. There will be 2 secondary tabs at the current Content page. See screenshots above.

Here's an updated patch that takes care of both points from #54/#55.

The combined patch includes the latest patches from #2852067-58: Add support for rendering computed fields to the "field" views field handler and #2862041-90: Provide useful Views filters for Content Moderation State fields.

If we make this view a sub-tab under admin/content, only users with "administer content" permission will be able to see this view. Is that its intended purpose?

@webchick, that's great to hear :)

Updated the empty text and changed the view and fallback route to use the 'access content overview' permission, which is also the one that's used by the main 'Administer content' view.

Looks like all boxes are ticked. So we should be good to move to RTBC, although it is still postponed on the other two issues.

Wow, this issue moved fast :) Looking great!

My only suggestion would be, we can go even shorter to something like "No moderated content (e.g. drafts) available". But we can do that post commit too!

Assuming that @xjm's comment from #2862041-91: Provide useful Views filters for Content Moderation State fields was meant for this issue:

We are also missing dedicated test coverage for the new view. There should be test coverage for all the twists and turns this issue has gone down in terms of what to display. This is not the kind of test coverage that should be scoped to followps.

Here's full test coverage for the new view :)

Also let's not mark this issue RTBC with a combined patch with others that haven't landed yet, and please provide the no-test patches so it's easier to read what's part of this issue. Thanks!

No-dependency patches have been posted here in #50, #59 and #63 (the ones without "-combined" in the file name).

The interdiff in #66 looks good, would RTBC but still waiting on #2852067: Add support for rendering computed fields to the "field" views field handler and #2862041: Provide useful Views filters for Content Moderation State fields.

I skimmed the issue, and it's not clear to me what this issue is blocked on, what this is actually doing and why the default /admin/content view is insufficient.

An IS update would do wonders — and I'm quite certain it'll help this issue get committed faster too :)

#2852067-69: Add support for rendering computed fields to the "field" views field handler has been committed and pushed to 8.5.x

One blocker down.

See comments over there in relation to this issue.

Rerolling now one of the blockers has been resolved.

Almost jumped off my chair when I saw the title change here :) But the second blocker is actually #2862041: Provide useful Views filters for Content Moderation State fields, so back to PP-1 for a bit longer.

@webchick, thanks for the new issue summary and for reviewing this again :)

Updated the path for the moderated content view (and fallback) to admin/content/moderated.. not sure why we didn't do that in the first place.

Since one of the blockers is still not in yet, I'm ok with doing more work in this issue, so I added a view and a fallback for custom blocks as well, plus tests. The thing is.. moderating custom blocks doesn't really do anything useful right now, you can change moderation states on them all you want but it won't publish/unpublish them automatically until #2820848: Make BlockContent entities publishable lands, so maybe we can get that committed as well :)

It was /admin/content/node/moderated because the standard content view is /admin/content/node although not sure why that doesn't resolve.

Forgot to change the path in the tests :/

None of my thoughts are going to override a release manager's decision, and you're probably right that it's very unlikely for #2820848: Make BlockContent entities publishable to get into 8.4.0 :/

So in the interest of keeping this issue shippable at any time, I've split the block_content parts of this patch to a separate issue: #2904997: Provide a way for users to moderate custom blocks

I will start picking up b), which should be resolvable.

Shipping without a UI sounds fine to me.

Thanks for the review @webchick, I too see no reason to not put this in 8.4.x along with #2862041: Provide useful Views filters for Content Moderation State fields, also worth noting #2852067: Add support for rendering computed fields to the "field" views field handler was only committed to 8.5.x, so needs to be cherry picked to 8.4.x.

Then once done we can commit #2897130: Mark workflows module as stable and #2897132: Mark Content Moderation module as stable

#2797583: Dynamically provide action plugins for every moderation state change will allow bulk update the moderation state. We can add the bulk form to the views added here.

Let's mark this RTBC once the blocker is in so that committers (me) don't repeatedly look at a patch that's not actually committable. :)

If some miracle happens and #2862041: Provide useful Views filters for Content Moderation State fields is committed in the next couple of days, this one should be ready as well, it just needs a few minor updates for the changes in that issue.

Blocker is in!

Here's a reroll fixing a conflict in ViewsData.

This is so exciting!!
Couldn't help myself so I tested the rerolled patch:

1. pulled latest 8.5.x, applied #93 and installed from scratch
2. enabled content moderation module
3. edited editorial workflow and enabled it for Articles
4. used devel_generate to generate some articles
5. edited the moderated_content view in search of errors, everything seems perfect, and the UI is working nicely

Anything we should be looking out while testing manually?

I'm clearly late for this party, but from a user perspective, I see this inconsistency regarding the Archived moderation state, which I think this will confuse content editors:

• On admin/content - an archived content shows with Status: Unpublished
• On admin/content/moderated - it shows with Moderation state: Archived

Could it be a better approach if content_moderation instead of providing a new tab for its UI, took over the view on admin/content to:

• Swap the Status column for Moderation state
• Swap the Published status exposed filter for Moderation state filter

This way, it would all be under the same screen, no context switching etc.

Only problem I can see is what could happen if the specific site is already taking over this view, but then the site owner would be responsible for handling this situation I suppose.

@Manuel Garcia, this was discussed previously in #30, and we need to have the Content Moderation as stable before doing anything about it.

I looked through the patch as well and I found a small thing that needed to be changed, we need a different description for the view instead of the copy/pasted "Find and manage content." :)

This was RTBC before #90 and nothing really changed since then.

Ah fair enough @amateescu - thanks for clarifying!

+++ b/core/modules/content_moderation/content_moderation.routing.yml
@@ -1,3 +1,11 @@
+content_moderation.admin_moderated_content:
+  path: '/admin/content/moderated'
+  defaults:
+    _controller: '\Drupal\content_moderation\Controller\ModeratedContentController::nodeListing'
+    _title: 'Moderated content'
+  requirements:
+    _permission: 'view any unpublished content'

At least 50% of this patch is the non-views fallback. I assume we more or less only do that because of #2804195: Views does not create parent local task for a default local task.

Fine to unblock content moderation, but trying to resolve that other issue would IMHO be really beneficial for a lot of sites, because this is a pattern that can be re-used for site-specific administration views, we often have a number of views for specific node types and so on, which we either have to put in the primary local tasks (which gets annoying when they are all collapsed together) or add custom code that tends to break easily.

At least 50% of this patch is the non-views fallback. I assume we more or less only do that because of #2804195: Views does not create parent local task for a default local task.

Nope, the non-views fallback is there just to provide a way to moderate content for sites that don't have views enabled :) See the second part ("In summary") of #30.

1. +++ b/core/modules/content_moderation/config/optional/views.view.moderated_content.yml
   @@ -0,0 +1,817 @@
   +          perm: 'view any unpublished content'
   

   Should this consider 'access content overview' in some way?

2. +++ b/core/modules/content_moderation/content_moderation.routing.yml
   @@ -1,3 +1,11 @@
   +    _controller: '\Drupal\content_moderation\Controller\ModeratedContentController::nodeListing'
   

   Pity we can't use _entity_list here and let EntityRouteEnhancer do the work we're doing in the ModeratedContentController? Would allow us to drop that class altogether. Can we get a follow up to make EntityRouteEnhancer more flexible - to support this type of use-case?

3. +++ b/core/modules/content_moderation/src/ModeratedNodeListBuilder.php
   @@ -0,0 +1,124 @@
   +    foreach ($this->getEntityRevisionIds() as $entity_id => $revision_id) {
   +      $entities[$entity_id] = $this->storage->loadRevision($revision_id);
   +    }
   ...
   +    $query = $this->entityTypeManager->getStorage('content_moderation_state')->getAggregateQuery()
   +      ->aggregate('content_entity_id', 'MAX')
   +      ->groupBy('content_entity_revision_id')
   +      ->condition('content_entity_type_id', $this->entityTypeId)
   +      ->condition('moderation_state', 'published', '<>')
   +      ->sort('content_entity_revision_id', 'DESC');
   +
   

   didn't we add a dedicated method/api to entity query for loading the latest revision?

   can we use that here?

2. I think this is the first time we've had that use case at least in core (adding additional list builders), not sure trying to generalize it is worth it without more use cases? And we would need to go much further than that, e.g. introducing a list_builders annotation with a nested array similar to form handlers but I'm not convinced yet that the complexity/impact is really worth (possibly deprecating the old key and so on..)

Yep, happy for people to say 'not worth it' or discuss is further on a new issue, where the resolution might be 'not needed'.

@larowlan, re #100:

1. It would be nice to also consider 'access content overview' but views does not support any kind of AND/OR permission grouping, so we can only specify a single permission.

In any case, 'view any unpublished content' implies more trust than 'access content overview' so I think we're good with using only that one.

3. We did but we can't use it here because this is an aggregated query on the content_moderation_state entity type, and we want the revision IDs of the *moderated* entities. We can however use the new loadMultipleRevisions() method :)

Think we can go back to RTBC now.

Is #100.2 something that would be better handled in a follow up?