Mark workflows module as stable

This is blocked on #2849827: Move workflow "settings" setters and getters to WorkflowTypeInterface, should this also be blocked on #2893778: Remove deprecated Workflows methods?

@timmillwood Perhaps a valuable intermediate can be to just mark them @internal. Less work, hence easier to land, but with the same end result: no need to support deprecated APIs.

I'd be more than happy to mark the methods in BC breaking follow-ups to #2849827 as @internal as a stop-gap if they can't be done before 8.4.0. I think that's a great compromise, but working on those patches now anyway, so fingers crossed.

#6: indeed! 🙏
#7: 👍

I think we can remove these now too.

Needs a reroll (at least for #2896721: Remove the concept of decorated states/transitions from worfklow type plugins. ).

Great work on stabilizing the APIs here. This is really close. In addition to finishing the must-haves and many of the should-haves, we're also supposed to include checking the core gates when we add new modules. I didn't see this on #2843494: WI: Workflows module roadmap so setting back to NR and will discuss in more detail on the plan issue. It'll be amazing if we can mark it stable for 8.4.x!

Actually postponing on #2843494: WI: Workflows module roadmap for now since we need to do some final reviews of the module and address core gates before marking it stable. Thanks @timmillwood. Hopefully we can make this change before beta! For now, for the alpha, I've marked Workflows as beta stability.

#2899553: Architectural review of the Workflows module (documentation cleanups) needs to be committed first though.

No problem, easy to overlook — it's been RTBC for 2 weeks.

The patch from #18 needed a reroll.

@catch and I agreed around the release of the alpha that the Workflows module was probably ready to be stable once all the must-haves were completed, based on its limited outstanding technical debt. (It's possible that some Workflows issues are actually filed against the content_moderation.module component, but on a 30s scan of that module's queue I only found one issue that needed to be moved.)

@webchick also signed off on the two remaining UI "should-have" issues, #2830584: Use modals for creating, updating, and deleting workflows, with a new DialogFormTrait and #2758623: [meta] Redesign workflow configuration page to better visually describe the flow, being okay as feature additions for 8.5.x+ if we mark Workflows stable in this release.

Normally, we would not add a new stable module to core after the beta deadline, but in this case, we already announced in the release notes that Workflows would probably become a stable module for 8.4.0.

I tried to commit this, but it does not apply even with @amateescu's reroll. :)

The patch needed another reroll after #2899553: Architectural review of the Workflows module (documentation cleanups).

Okay, take two. Starting from where I left off in #30:

• I confirmed that the only remaining @internal are retained on purpose, and they reference #2897148: Remove @internal from workflowHasData/workflowStateHasData and use those methods for access control and configuration validation. specifically, so that makes sense.
• The must-haves on the roadmap are complete and the outstanding should-haves are okay to add in 8.5.x+.
• There aren't that many known issues.
• The module has had a full architectural review and has adequate test coverage.
• Workflows does not provide any templates or CSS, so there's nothing we need to add to Stable for it.
• I confirmed that the hook_help(), while a bit short, is at least not an empty stub. The linked handbook page at https://www.drupal.org/docs/8/core/modules/workflows is also pretty thin, but does contain some information, including the important point that Workflows itself isn't going to be that useful and that Content Moderation is where the features are at. Ideally I'd want to see a bit more information, like:
• Definitions for what workflows, states, and transitions each are.
• Screenshots and explanations for how to use the UI. Some of this seems to live in the Content Moderation handbook right now; maybe we need to do a documentation update based on the refactoring from the last release? The section under "Configuring a workflow" can probably be moved over directly.
• Maybe a bit more information on how to implement the API, although what's there is enough to get people started, so that is good.
• The module has already had a usability review, and the product management team signed off on the module being stable with the current UI (without the modal issue).
• No critical path performance impacts since it doesn't do anything by itself. :)
• No known security or data integrity issues. (The recently resolved data integrity issues were specific to Content Moderation and revisioning.)

If someone wants to fix the handbook page by moving that one section over from Content Moderation (and then just having the Content Moderation handbook page link it), plus adding the definitions of the three terms, I think this is ready!

Come to think of it, the definitions of workflows, states, and transitions should probably go in the hook_help() directly.

For the views module we have links like this /admin/structure/views/view/content and for the workflows module we have links like /admin/config/workflow/workflows/manage/editorial I think it should be /admin/config/workflows/workflow/manage/editorial. Thoughts?

"workflow" is the category and "workflows" is the module name, so I think this is fine.

@timmillwood that's fine but don't you think /admin/config/workflows/workflow/manage/editorial makes more sense?

BTW I agree the IA for workflows could use improvement. Workflow, Workflows, Workflows, Workflows! :) But I think that can happen in any minor and doesn't need to block the module being marked stable. @jibran, can you maybe file an issue for that?

Thanks @timmillwood for the updated docs. I think this is ready!

Fixed a coding standards error on commit:

diff --git a/core/modules/workflows/workflows.module b/core/modules/workflows/workflows.module
-      $output .= '<h4>' . t('State'). '</h4>';
+      $output .= '<h4>' . t('State') . '</h4>';

YAYYYYYYY!!!!!!!!!!!!!!

But … I'm very sorry, but …

+++ b/core/modules/workflows/src/StateInterface.php
@@ -4,10 +4,6 @@
- * @internal
- *   The StateInterface should only be used by Workflows and Content Moderation.
- *   @todo Revisit the need for this in https://www.drupal.org/node/2902309.

+++ b/core/modules/workflows/src/TransitionInterface.php
@@ -4,11 +4,6 @@
- * @internal
- *   The TransitionInterface should only be used by Workflows and Content
- *   Moderation.
- *   @todo Revisit the need for this in https://www.drupal.org/node/2902309.

These should not have been removed. they still have a @todo. Can we just revert these two hunks?

Hm yep, in an earlier patch those hunks were not removed; accident in the reroll I guess. @Wim Leers, can you provide a followup patch? That would be easiest.

Sending to testbot.

Committing this from NR since it's just a followup. ;)

Fixed the formatting on commit:

diff --git a/core/modules/workflows/src/StateInterface.php b/core/modules/workflows/src/StateInterface.php
index 6cc8ace95c..3335ea7452 100644
--- a/core/modules/workflows/src/StateInterface.php
+++ b/core/modules/workflows/src/StateInterface.php
@@ -7,7 +7,7 @@
  *
  * @internal
  *   The StateInterface should only be used by Workflows and Content Moderation.
- *   @todo Revisit the need for this in https://www.drupal.org/node/2902309.
+ * @todo Revisit the need for this in https://www.drupal.org/node/2902309.
  */
 interface StateInterface {
 
diff --git a/core/modules/workflows/src/TransitionInterface.php b/core/modules/workflows/src/TransitionInterface.php
index 0fa159cabf..ae3f0231be 100644
--- a/core/modules/workflows/src/TransitionInterface.php
+++ b/core/modules/workflows/src/TransitionInterface.php
@@ -8,7 +8,8 @@
  * @internal
  *   The TransitionInterface should only be used by Workflows and Content
  *   Moderation.
- *   @todo Revisit the need for this in https://www.drupal.org/node/2902309.
+ *
+ * @todo Revisit the need for this in https://www.drupal.org/node/2902309.
  */
 interface TransitionInterface {
 

Thanks!

🎉