Problem/Motivation

Workflows currently provides StateInterface and TransitionInterface for the State and Transition value objects. Content Moderation also uses StateInterface for ContentModerationState value object.

Do we need these interfaces?

Discussion started in #2899553: Architectural review of the Workflows module (documentation cleanups) at #29.

Proposed resolution

Discuss.

Remaining tasks

User interface changes

API changes

Possible removal of these two internal interfaces.

Data model changes

Comments

timmillwood created an issue. See original summary.

sam152’s picture

sam152 commented

If there are two implementations, the interface is required. So perhaps the issue should clarify the terminology around "value objects" in the comments?

sam152’s picture

sam152 commented
Issue summary: View changes
Related issues: +#2899553: Architectural review of the Workflows module (documentation cleanups)

Given we have methods like WorkflowTypeInterface::getTransitions which are @api that return an array of objects that implement an @internal interface, this should probably be resolved for 8.5.

Additionally I missed that #2896724: Create constants for transition directions. introduced a constant on an @internal interface, to be used as an argument for an @api method. I suspect the outcome of this will be, those interfaces will become @api, so hopefully not an actual problem?

Adding some context to the IS which will help us decide what to do with these.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

nigelcunningham’s picture

nigelcunningham commented

I have a further argument for treating Transitions as entities in their own right: I'm preparing a quote for a client that wants transitions to require approval from multiple users. To my mind, it makes most sense to implement this by having transitions be entities supporting the implementation of the rules that are required.

If this quote goes further, I'll do more work but happy to participate in further discussion.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

smustgrave’s picture

smustgrave commented
Status: Active » Postponed (maintainer needs more info)
Issue tags: +stale-issue-cleanup

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

amateescu’s picture

amateescu commented
Status: Postponed (maintainer needs more info) » Active

I think this still needs to be settled, and the answer for the decision part is "yes" from my POV.

Both Content Moderation in core and other projects in contrib provide their own value objects for states and transition, and it would be nice to have at least the common methods on an interface.

mile23’s picture

mile23
Primary language English
Location Seattle, WA
commented

Coming at this because I needed to understand workflow/content moderation stuff for a project, and I encountered the @todo in Drupal\workflows\StateInterface...

Drupal\content_moderation\ContentModerationState is a decorator for an arbitrary Drupal\workflows\StateInterface object, so it needs to implement all the methods of StateInterface.

Therefore, ContentModerationState should identify itself as implementing Drupal\workflows\StateInterface, which it currently does.

If we need an interface which extends StateInterface to include the extra decorations from ContentModerationState, then we should add that in content_moderation module. It could be named something like ContentModerationStateInterface.

I'm finding it hard to figure out what the actual proposed change in this issues is, so I'm not sure if I agree or disagree with it. :-)

Change I propose: StateInterface should not be @internal, and should have the @todo removed.