I have tested this and it does what it says but for me its a major loss of functionality to just remove the versioning of the state. I do not consider this as a fix for the release blocker.

Thank you @brianteeman for testing and giving feedback.

Do we agree, that a user should not change values which are handled by the workflow?

The issue is, that the value are not saved at all and the solution should be, that the values are saved but only recovered when the workflow is disabled?

Do we agree, that a user should not change values which are handled by the workflow?

honestly not sure. it would depend on the workflow settings

Just by the way, the failure of system tests in Drone seems not to be related to the PR but to a problem with testing environment ("Failed to connect to 127.0.0.1 port ...: Connection refused", like we currently have it for other J4 PRs.

Do we agree, that a user should not change values which are handled by the workflow?

honestly not sure. it would depend on the workflow settings

If you disable the e.g. the publishing plugin, then it's versioned. So the settings have an impact.

Editor submits a new version. Admin check it and says no so they need to revert to the previous version

can they still do that?

Editor submits a new version. Admin check it and says no so they need to revert to the previous version

can they still do that?

Yes, they can revert every value they could also change in the normal edit form. So e.g. title, text, dates etc. but not "state" and "featured" if (!) they are enabled within the workflow.

I'm going to merge this because this is at least more consistent. However I'm not going to close the original issue for now because potentially there could be better fixes.

Editor submits a new version. Admin check it and says no so they need to revert to the previous version

In this case if the article is already published the editor version is also live before admin review. If the article isn't live then state won't have changed. If the state has changed between the new version and the admin publishing then you're reverting multiple versions and potentially yes you wouldn't see a rollback. Potentially I guess if there is a path in workflow to revert the workflow state maybe we should execute it (or else not allow the rollback??) But super unsure which is why I'm happy to keep the existing issue open to discuss these kinds of concrete use cases.

@HLeithner also made a good point that right now hitting publish in the list view doesn't trigger versioning (I mean for sure I'd see that as a bug but...) state is already inconsistent in j3/j4 - probably just needs more work overall.