Dispatch events for changing content moderation states

That also needed to happen in tests.
Fixed that, and the method signature forces us to return something (usually the event itself). This should be green.

Next step should be fixing the php10 deprecation warnings.

That was the interdiff only... not even properly named.

The last submitted patch, 73: 2873287-content-moderation-events-72.patch, failed testing. View results →

Rewritten the test based on 📌 InvocationMocker::withConsecutive() is deprecated in PHPUnit 9.6 and removed from PHPUnit 10 RTBC . Added a todo if this lands before that one. No deprecations anymore.
I feel like writing tests will be even harder now :-(

Mostly code standards, but I changed an exactly(5) to any() in previous patch and I reverted that back.

Per #39 still NW.

Just another rebase, conflict on the save method changes.

Updated remaining tasks to include #39 + change record.

patch from #76 does not apply to 10.2.2

for 10.2.x use patch from #79

Hi, I was looking for this functionality, its great for being informed of a transition event, but what about being able to veto the transition?

Use case: Product publication.

A user wants to validate a product ready for publication. The system needs to check that the product is really ready. Maybe they haven't filled in all the required fields for publication (fields which cannot be required to create the initial entity/node). Maybe they haven't prepared related content which is required for publication.

The system should be able to validate certain data before allowing the product to pass to a validated state.

Previously we used the "Workflow" module but we decided against it because the module doesn't seem to be maintained and the code base is still in a state of temporary migration from Drupal 7 style code. Content Moderation seemed to be the more accepted option however it is limited in this respect.

@willeaton: You might find State Machine → suitable for your needs. It provides / supports "Guards" which are plugins you can define to prevent specific state transitions if certain conditions are not met. But we're getting a bit off topic from this issue.

I also needed something like this for a project, but this issue seems a potentially doomed in deadlock between release manager and subsystem maintainer. I'm not sure I can be more persuasive than what @Sam152 already said in #40 and #45. Yes, a mix of hooks and events is somewhat crappy DX, but so is the current situation. I'm not sure how we provide 100% BC without a mix of both unless we want to make ContentModerationState public API. Drupal seems to love to provide a lot of different ways to alter the same thing 😅 so I'm not totally convinced that having both Events and hooks is really all that terrible. 😂

+1 to doing this. If I can find more time for a direct (and hopefully persuasive) response to every point in #39, I'll try.