Enable Content Moderation integration for taxonomy terms

I've applied and tested patch from #32 on Drupal 9.5.2 and it works just great.

@jurgenhaas, thanks for reporting that the patch is working for you and the version of Drupal it is being used on.

The Issue Summary is clear.

Going through the comments I see that the following have not been addressed

• #13 📌 Enable Content Moderation integration for taxonomy terms Fixed - The commented out line is still in the patch.
• #21 📌 Enable Content Moderation integration for taxonomy terms Fixed

I skimmed the patch and noticed the following items.

1. +++ b/core/modules/content_moderation/tests/src/Kernel/ContentModerationStateTest.php
   @@ -278,7 +282,7 @@ public function testContentModerationStateTranslationDataRemoval($entity_type_id
   +      $translation = $entity->addTranslation($langcode, [$entity->getEntityType()->getKey('label') => 'French title test']);
   

   This looks to be out of scope.

2. +++ b/core/modules/taxonomy/tests/src/Functional/TaxonomyTermContentModerationTest.php
   @@ -0,0 +1,201 @@
   +    // Add a pending revision and change the parent.
   

   It would be easier to follow if parent_1 was used here. The same applies to other comments. As in 'change the parent to parent_2' and so on.

3. +++ b/core/modules/taxonomy/tests/src/Functional/TaxonomyTermContentModerationTest.php
   @@ -0,0 +1,201 @@
   +    //$this->assertSession()->pageTextNotContains($validation_message);
   

   Why is this commented out?

I saw an @todo in the code for this issue. A search of core needs to be done to check for all instances and determine if the todo can be deleted.

Oh sorry for that @quietone - as the issue was NR I thought that all that had been addressed. Will be more cautious next time.

I can't see how this could get merged without resolving #3145661: Users without "administer taxonomy" permission can't see unpublished terms canonical pages → . The expectation of enabling Content Moderation on Taxonomy Terms is going to be that the responsibility could be assigned to the same roles as other types of content. Requiring Administer Taxonomy for this seems wrong.

Not sure if the lack of a View filter would get resolved here or in a follow-up issue, but this is another place where it won't work the way most people expect.

Posting a patch from the last MR push because I need an immutable patch.

From what I can tell points in #39 have not been addressed.

Which also mentions other comments not addressed.

Added permission check for view all revisions - @kreynen is correct.

One thing noticed that once taxonomy term published and then moved to Draft, still the term is in published.

It's the same behavior for nodes.

Yep. The draft version is "ahead" of the currently published version until it is published.

I chose the Node permission "view all revisions" and this is definitely wrong. The issue https://www.drupal.org/project/drupal/issues/2936995 📌 Add taxonomy term revision UI RTBC provides revision permissions and should probably be a blocker for this issue.

The current MR solved my original issue, but our use case is only using moderation on a single vocabulary. I agree with @slydevil that it makes more sense to use view terms revisions in $id, but then we just get to the next place where the experience of managing drafts of terms doesn't have feature parity with content.

I added ✨ Add Status to OverviewTerms.php form Fixed and proposed a patch to add Status to the Terms Overview UI. Unlike the Content Overview, admin/structure/taxonomy/manage/[tid[/overview is not a View and there is no support to filter terms by moderation state making it hard to add the UI users are used to seeing in Content.

I'm not sure if the goal is to make incremental progress on this in multiple issues or propose a single MR that would provide the type of features users will expect to see when enabling moderation on a specific Vocabulary.

We have a project using 9.3.2, Acquia_CMS 1.4.0.
We added node type and/or taxonomy to a workflow item.
We tried enable_content_moderation_for_terms-3047110-49.patch.
We're using 3047110-32.patch to enable moderation for taxonomy_term.
We contacted Acquia Support.
We are failing at UNPUBLISHING either node or taxonomy_term.

Is anyone experience this issue and how to fix it?

I'm thinking that the feature can do this:
- User can specify a state as published.
- When user set the state, the feature will set entity.status to 1.
I'm thinking that the feature CAN NOT do this at the moment:
- User no need to specify states as unpublished.
- When user set a state other than the state-as-published, the feature won't set entity.status to 0.

If someone can help I'm willing to share what more needed detail.
It's been 1/2 year already.
Thanks in advance!

Woot! ✨ Add Status to OverviewTerms.php form Fixed was merged into core! Small step, but it improves the core UI when using this patch.

Woot! #3359159: Add Status to OverviewTerms.php form was merged into core! Small step, but it improves the core UI when using this patch.

Hey thanks for that, a good improvement indeed!

Adding related revisions UI issue.

Rerolled with 11.x.

Setting this back to needs review. The issues in #39, #47 seem to have been addressed except no1 in #39 which I don't think is out of scope since we need content moderation to be testing for taxonomy_term entity as well which may have a different entity key for label than other entities which may use "title".

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

@sakthi_dev please do not upload patches, this issue is using an MR and patches are confusing the bot.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

acbramley → changed the visibility of the branch 3047110-enable-content-moderation-9.5.x to hidden.

Oh! The MR is still against 10.x. We either need it rebased against 11.x, or it's probably easier to create a new branch off 11.x and apply the changes (which seem like they're not applying cleanly according to the bot)

I've hidden the 9.5.x branch

Created a new branch from 11.x and cherrypicked the commits onto it.

acbramley → changed the visibility of the branch 3047110-enable-content-moderation to hidden.

We're missing a moderation handler here too, see BlockContentModerationHandler

Great work on the MR, I think now we just need an IS update and a CR.

Change record added https://www.drupal.org/node/3424780 → and issue summary updated.

Great job @pavlosdan, thank you for pushing this along - the only thing for me now is whether we have enough test coverage or not. CM is a huge layer of complexity, but the test coverage in the MR (along with existing test coverage that we're enabling for taxonomy terms) seems quite thorough.

I think we're good to go!

Thank you for the reviews and suggestions @acbramley!

I think the test coverage is fine; the actual changes here are minimal and this functionality is already tested, we just need to ensure it's extended for this entity type which has been done here.

Committed and pushed 07473ef250 to 11.x and 2d61a0ef34 to 10.3.x. Thanks!

longwave → closed merge request !6825

Automatically closed - issue fixed for 2 weeks with no activity.