The view installed by content moderation assumes the 'editorial' workflow installed by standard profile exists

This came up as a #bugsmash daily issue.

I tried replicating on a fresh Drupal install
Installed the Content Moderation module (which installed Workflows)
And check the Content Moderated view and did not see any errors.

Also checked the logs and did not see anything.

If there a step missing or can we say this issue has been resolved?

Steps to reproduce:
* Do a minimal install of Drupal
** Install some themes and toolbar to not go crazy
* Enable Views module -> save
* Enable Content moderation
* Check Moderated content View
* See broken handlers:

So to me, the problem here is that this View ships without a config dependency on this specific Workflow, which it should, since it has one.
Good thing is, if you install all this in something like Umami and then resave the View and check its dependencies, this workflow dependency is added, so it seems to be purely that the optional config is missing this.

So to me, the easy solution here is to add that dependency to the View and then I shouldn't get installed if you don't have this Workflow.

I ran into the broken/missing handler issue mentioned in #21 🐛 The view installed by content moderation assumes the 'editorial' workflow installed by standard profile exists Needs review during todays weekly lean coffee call of the drupal user group munich. when i wanted to locally test an issue we were talking about in relation to content moderation i've noticed the broken/missing handler for the first time on a fresh install. after the call i've checked the issue queue for existing issues and arrived here.

1. if you install 9.5 or 10.1 with the standard profile, then install the content moderation module, and finally check the moderated content view you will have a broken/missing handler at the fourth position in fields and at the fourth and sixth position forfilter criteria. took us a while to figure out, but the problem causing that issue is if you go to admin/config/workflow/workflows/manage/editorial?destination=/admin/config/workflow/workflows into the This workflow applies to: section, there is no entity type selected there. that is causing the broken/missing handler field and filter criteria entries. if you select at least one the broken/missing handler is gone on the view.
After that i've simply deleted the Editorial workflow. i then revisited the moderated content view again and i am able to reproduce the No valid values found on filter: Content revision: Moderation state. as described in the issue summary.

2. if i install drupal with the minimal profile i get broken/missing handler described in #21 🐛 The view installed by content moderation assumes the 'editorial' workflow installed by standard profile exists Needs review . but there is no Editorial workflow installed. so in contrast to 1 i dont get the No valid values found on filter: Content revision: Moderation state.error but the broken/missing handler.

I wonder if aside the suggestion in #22 🐛 The view installed by content moderation assumes the 'editorial' workflow installed by standard profile exists Needs review it would make sense to pre select at least one or two existing entity types in the standard profile (article and basic page, and/or basic block) for the editorial workflow?

I ran into this as well. Indeed, it seems the problem is that when the standard Workflow is deleted, that filter "Content revision: Moderation state (<> Published)" on the view no longer works. It gets changed to "Content revision: Moderation state (<> Unknown)" It must be fixed manually by editing the filter and selecting the appropriate "Published" state from the new workflow(s) on your site. Not sure there's a good way for the Content Moderation module to do this automatically?

The dependent configuration this view assumes could be moved or copied to this module's config/optional folder.

Something like this?

Added standard workflow to config/optional folder
Added dependency to workflows to view

The last submitted patch, 26: 3088534-26.patch, failed testing. View results →

Added a check to the test trait for creating the editorial workflow.

The last submitted patch, 28: 3088534-28.patch, failed testing. View results →

Removed

    // Test a node for a workflow that hasn't been updated to include the
    // 'default_moderation_state' setting. We must be backwards compatible with
    // configuration that was exported before this change was introduced.
    $this->assertFalse(isset($configuration['default_moderation_state']));

Felt it was testing something that is no longer true by adding the workflow config with content_moderation

Using Drupal 10.1.2, #9 🐛 The view installed by content moderation assumes the 'editorial' workflow installed by standard profile exists Needs review which is explained in more detail at #24 🐛 The view installed by content moderation assumes the 'editorial' workflow installed by standard profile exists Needs review worked for me.

I had also found this before, see #3060633: Check that views do not get created with broken handlers → . That is more about preventing something like this in general, though.

It seems like we're copying the workflow. Should we be moving it from standard profile instead?

You mean remove it completely from standard? Will that mean the config should still be optional?

If moving it makes more sense, I think it belongs in config/install, as it doesn't have any other dependencies that would make it optional. In the standard profile, it is only dependent on this, the content_moderation module where it would be moved.

dependencies:
  module:
    - content_moderation

Moved into config/install and removed from standard profile.

Changed to MR because gitlab is way faster

I think this looks great! I assume this needs a change record and release note.

I don't understand the removal of the assertion completely, but I guess it makes sense. (Discussed in #30).

I know in #33 I said I thought we should be moving.

But after re-reading the comments on the issue, that by @Lendude in #22 seems like the correct fix.

i.e this view should not be installed if you don't have the workflow.

It doesn't sound like that was explored.

Can we explore that? It would be a one-line fix.

smustgrave → changed the visibility of the branch 3088534-the-view-installed to hidden.

Added a new MR with the 1 liner.

Tests are green with the one liner. Manually tested with the steps to reproduce from the IS and the broken handlers are still present.

Steps to reproduce:
- Minimal drupal install
- Enabled Claro and Olivero, set as defaults
- Enable views & views UI -> install
- Enable Content moderation -> install
- Edit view "Moderated content" --> Broken handlers
- Check Configuration -> Workflow --> No workflows

Screenshot of the view config:

I think the dependency should be on the editorial workflow config (workflows.workflow.editorial) not the workflow module itself. That should make sure there are no broken handlers.

Hmm doesn't seem to work either. Changing that doesn't even get the content moderation view installed 🤔

Somewhat working:

dependencies:
  module:
    - node
    - user
  enforced:
    module:
      - content_moderation
      - workflows
    config:
      - workflows.workflow.editorial

Also copied the workflows.workflow.editorial.yml from the standard profile into the optional config.

This installs the modules, adds the editorial workflow and creates the view. But unfortunately, all 3 handlers remain broken and re-saving the view doesn't fix this.

Hmm... maybe you are running into the issue I described over at #3060633: Check that views do not get created with broken handlers → which is the ordering of the import. Not sure where you copied the workflow config to, but if you copied it into the Minimal profile it will be installed after the view, so at that point the view will already have been created with the broken handlers.

Also copied the workflows.workflow.editorial.yml from the standard profile into the optional config.

Meaning into "core/modules/content_moderation/config/optional/". I did not copy it into the minimal profile. I also tried moving from /optional to /install but that has the same result.

So would the original MR work? Currently hidden

Re #48, right, sorry, my explanation made no sense, with the dependency the view would not have been installed then. Not sure what ist going in then...

No that's right

We want the view to depend on the workflow
And we want it in optional condig

Hmm, so now (my latest commit) we have the expected behaviour on minimal (no view nor workflow). But on the standard profile it's still showing 3 broken handlers.

I manually tested #52 and got the same

The missing piece of the puzzle is you need to edit the workflow and enable it for some content types.

So I think the fix is that the copy of workflow.workflow.editorial that is in standard/config/optional needs to have it enabled for the content types (basic page, article)

Pushed #53

The missing piece of the puzzle is you need to edit the workflow and enable it for some content types.

💡🎰 Yes, that is exactly what was missing at least in my understanding of the issue. Thanks, I will wander the earth in a slightly less confused state now thanks to you. 😉

Manually tested this again, and fixed one PHPCS remark. All looks good now!

Actually there are two tests failing.

DefaultConfigTest https://git.drupalcode.org/issue/drupal-3088534/-/jobs/577863#L2612
ModeratedContentViewTest https://git.drupalcode.org/issue/drupal-3088534/-/jobs/577855#L1867