Problem/Motivation

Workflows are protected from being deleted if they contain data, but the module that provides the workflow type can still be uninstalled.

Proposed resolution

Prevent modules that provide workflow types that are in use from being uninstalled.

Remaining tasks

Discuss, add test coverage.

User interface changes

Nope.

API changes

Nope.

Data model changes

Nope.

Comments

amateescu created an issue. See original summary.

amateescu’s picture

Issue tags: +Needs tests
StatusFileSize
new6.42 KB

This is what I had in mind. I tested it manually and it works, but we still need automated test coverage.

sam152’s picture

The ContentModerationState entity exists so that content_moderation could be uninstalled, with moderated content, while it was experimental. The editorial workflow config entity also has a dependency on content_moderation, so I assume that'd also be deleted if someone tried to uninstall content_moderation.

Does this patch stop implementations like content_moderation deciding that they can safely clean up on uninstall?

amateescu’s picture

Status: Active » Needs review
Issue tags: -Needs tests
StatusFileSize
new9.58 KB
new3.15 KB

Does this patch stop implementations like content_moderation deciding that they can safely clean up on uninstall?

Nope, because \Drupal\content_moderation\Plugin\WorkflowType\ContentModeration::workflowHasData() decides whether it has data or not based on the existence of content_moderation_state entities using that workflow. After we delete those entities, the method will return FALSE so the Content Moderation can be uninstalled :)

Here's the required test coverage. A test-only patch is not needed because this is a new functionality for the Workflows module.

sam152’s picture

StatusFileSize
new36.45 KB

So in the case of the content_moderation plugin, it can't be uninstalled without the relevant data being purged anyway, so does this solution add any checks and balances we don't already have?

In the case of an implementation that provides a @FieldType, core has similar protections for modules providing field types built in, so this wouldn't affect that either right?

In another completely hypothetical use of @WorkflowType, who is to say uninstalling the module doesn't also remove the associated thing-being-workflowed™, even if that thing is TRUE for hasData and that's the expected and intended behavior?

amateescu’s picture

So in the case of the content_moderation plugin, it can't be uninstalled without the relevant data being purged anyway, so does this solution add any checks and balances we don't already have?

Nope, this doesn't change anything for content_moderation :)

In the case of an implementation that provides a @FieldType, core has similar protections for modules providing field types built in, so this wouldn't affect that either right?

Right.

In another completely hypothetical use of @WorkflowType, who is to say uninstalling the module doesn't also remove the associated thing-being-workflowed™, even if that thing is TRUE for hasData and that's the expected and intended behavior?

If hasData returns TRUE for whatever reason, it means that there *must* be a way to remove that data, just like field types can be uninstalled by removing all fields that use them.

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

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should 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.

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

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should 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.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.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: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should 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: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev
ranjith_kumar_k_u’s picture

StatusFileSize
new9.45 KB

Re-rolled #4 for 9.4.

ranjith_kumar_k_u’s picture

StatusFileSize
new9.45 KB
new554 bytes

Fixed CS errors.

Status: Needs review » Needs work

The last submitted patch, 14: 2904101-14.patch, failed testing. View results

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

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should 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.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should 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: 9.5.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. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

acbramley’s picture

Needs a reroll into an MR and quite a bit of refactoring to be in line with modern practices (strict types, etc)

Do we have an example workflow type in contrib that would benefit from this? I.e workflowHasData returns TRUE when there are no entities provided by the module?

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.