Retain last revision info when bulk unpublishing

Automatically closed - issue fixed for 2 weeks with no activity.

@joseph.olstad I appreciate your initiative, but this was unfortunately a work in progress that I hadn't marked as ready for review. Would you mind reverting that commit? It's not complete unfortunately and it causes a PHP error in its current state.

Also - I'm not sure it makes sense to extend this to the unpublish/archive actions. In my testing, the publish action did not create a new revision, but the archive/unpublish action DOES create a new revision of the node.

There's a conflict reverting this.

Thank you! I'll let you know when I'm ready for a review :)

this was not tagged so there's no need to publish a release to revert.

Alrighty, I created a new merge request that I actually did some testing with.

In looking deeper at the code, only the publish action does not create a new revision but instead updates the latest one.

Given that, the code needs to treat that action slightly differently. With the publish action, we retain all the original revision information (author, date, message) and simply append information about who/when bulk publishing occurred.

For all other operations where there is a new revision created, I'm leaving the new revision information mostly untouched but append information (if it exists) about the last revision of the entity to the bulk message.

This will help our use case and it does remove a bit of code duplication even if someone isn't using the new setting.
But - I'm not sure how widely useful this is for non-publish actions (in other site use cases). Let me know what you think, and please test with and without the new "retain revision info" option enabled.

Ok great, thanks for this, it looks very good.

If we're happy with it, put it in the 2.0.x dev , and then let it simmer in there for a while.

Hey Joseph, this isn't directly related to the functionality of this ticket, but I'm noticing something strange when using the module with media entities.

There's a different process for using this module with a media view ( ✨ Views Bulk Operations Actions for media entities Active ) - which is fine. However, when using that approach, the "Archive Current Revision" action does not appear - just the publish/unpublish current revision.

That's not a big deal, but it looks like the "unpublish" action in this module runs the archive action first - and then runs the draft action on top of it.

You end up with a content entity that is unpublished but in a draft vs archived moderation state. I'm not sure the best approach here, but this issue is highlighted with this patch applied because it's appending both moderation state changes in the revision log message.

Example:
"Bulk operation create draft revision. Last revision message: Bulk operation create archived revision. Last revision message: This content is ready to unpublish"

In #3253887: Change revision message on bulk Unpublish → someone else mentioned how the current log message is confusing, and I can definitely see why now. Is there a reason the unpublish revision doesn't just set to the archived state and only fallback to the draft state if no archive state was found?

I went ahead an made adjustments to only have the archive change happen on the "unpublish" action with the draft as a fallback. It does eliminate quite a bit of duplicate code and results in a log message that I think makes more sense and an end moderation state of whatever the archived one is (if available).

I recognize that the scope is increased though.

ok sure, sounds like a good idea. I'll plan to do some testing on this in the comming weeks . Meanwhile I applaud any others wishing to help review and test this.

This works for me (drupal 10.4.7)

This works as advertised for me (drupal 10.4.7; sorry for the double post, I missed updating the status)

Cool, thanks for testing, this is on my radar 100%, I'd like to test a few of my multilingual setups , we tend to publish and unpublish both of our languages at the same time.

That's a really good idea since I don't do much multi-lingual.

I'm also thinking of tweaking this so that the behavior with the retain revision info setting makes a new revision when publishing. It seems really odd for that action to be different than the others -

jastraat → closed merge request !42

jastraat → changed the visibility of the branch 3522425-retain-last-revision to hidden.

Joseph I created a fresh branch with a fresh MR that does the following:

• Uses "draft" as the fallback for the unpublish action instead of updating the entity a 2nd time within the same action. (from previous MR)
• Consolidates all revision related updates to a separate function.
• If the retain revision info setting is on and there was a revision message in the last revision, append it to the bulk operation log message. (from previous MR)
• If the retain revision info setting is on, the publish action creates a new revision just like it would if the entity was published using the entity form. (new)
• If creating a new revision, make sure to update the changed date on the entity itself similar to what would happen if the entity was published/archived using the entity form. (new)

I haven't tested this but 100% for sure this will cause a regression for mulitilingual workflows.

I just updated this slightly to still load the latest revision but to simply refrain from setting syncing to true if the revision info is being retained. This is a slightly smaller difference than the previous one and allows media to be supported again.