Provide users with the option to select an appropriate moderation state when reverting to a previous revision

Fixed the failure. I don't think #65 is valid considering we have tests covering this functionality.

The last submitted patch, 76: 2906568-76.patch, failed testing. View results →

Fixed comparison of strings vs FormattableMarkup, added return types.

The patch on #78 works for me just for sites without translate content enabled, that is because the route for content with translation is node.revision_revert_translation_confirm so we should also add a form for these cases and assign it to the mentioned route.

This would be a great feature to have. Can we update the issue summary with the agreed upon solution though?

Also have posted in the #ux for usability review so hopefully happens soon.

Re-rolled and created MR against 11.x

Had the same thought as #51, this is very specific to nodes and I'm not sure it needs to be.

Re #85 - it doesn't need to be but we are quite a way off using the generic UI for Nodes.

Adding patch of MR5696 at commit 3ba5a1a1 for anybody needing a stable patch against 10.2

When I revert a revision to Draft, it is updating the published SQL table for my field (eg: paragraph__field_X), as well as creating a new row in the revisions table (paragraph_revision__field_X). This does not happen when you make a new draft - only when you revert to a draft.

I noticed this because I have some custom code elsewhere that is manually querying the non-revision SQL table for my field and I was surprised to find the reverted draft values instead of the published values.

It looks like we call prepareRevertedRevision which is hard-coded to $revision->isDefaultRevision(TRUE);. Is this correct? Seems like it should be false if reverting to a draft.

When I revert a revision to Draft, it is updating the published SQL table for my field (eg: paragraph__field_X), as well as creating a new row in the revisions table (paragraph_revision__field_X). This does not happen when you make a new draft - only when you revert to a draft.

I noticed this because I have some custom code elsewhere that is manually querying the non-revision SQL table for my field and I was surprised to find the reverted draft values instead of the published values.

It looks like we call prepareRevertedRevision which is hard-coded to $revision->isDefaultRevision(TRUE);. Is this correct? Seems like it should be false if reverting to a draft.

That seemed to have fixed the issue for me. Attached is my patch.

Patch updated with translation support

Updated route subscriber to work on multilingual sites

Anyone else struggling to patch against 10.3.0 ?

@opi I've attached the patch we're using for 10.3.0, but I have set it to hidden so as not to confuse this issue further. This is based on the patch in #87 as that's what we were previously using and I haven't reviewed 89-91, which don't have interdiffs and aren't in sync with the MR.

@mstrelan Thanks a lot ! I wasn't brave enough to rebase a 21KB patch last evening <3

re-rolled against 10.3.1, but I did not bother with the tests