Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Editing a node with VBO doesn't create a new revision even if the content type is configured to create new node revisions.
How to reproduce:
- Create a content type with 'create new revision' ticked
- Create a content
- Edit a field with VBO
- Note that no new revision was created but that the modification is considered to be part of the previous revision
According to https://www.drupal.org/node/478152 and https://www.drupal.org/node/689498 this is fixed in D6.
Comment | File | Size | Author |
---|---|---|---|
#15 | 2474691-15-node_revisions_support.patch | 1.32 KB | Itangalo |
#14 | 2474691-2-node_revisions_support.patch | 1.26 KB | Itangalo |
#12 | 2474691-node_revisions_support.patch | 967 bytes | Itangalo |
Comments
Comment #1
grahor_targ CreditAttribution: grahor_targ as a volunteer commentedFor those, who aren't inclined to wait for a fix, but need a workaround for the issue right now, that's what I've done:
In my bulk action I've changed not just a field that needs changing, but also I've set $node->revision to 1 and $node->log to my custom text. New revision was created, previous revision wasn't overwritten.
Relevant part of my code, you could do the same simply with $node->revision=1:
Comment #2
Rustan CreditAttribution: Rustan commentedI have this issue as well.
@grahor_targ Can you describe your solution in a bit more detail? Where did you make these additions, as part of the bulk view?
Comment #3
SseggembeMoses CreditAttribution: SseggembeMoses commentedIn your view, Click on your bulk operations Field. Then Go to " selected Bulk operations " and tick "Modify entity values" and under that, go to " OPERATION SETTINGS " and then select " creates revision ", hold CTRL button to select other fields to update. Save.
You can now test, it should create revisions for each of the nodes.
Hope that helps.
PS i use latest versions of VBO, Revisioning and Workbench moderation
Comment #4
Rustan CreditAttribution: Rustan commentedThanks @SseggembeMoses ! I had totally missed that option. Works fine, but it has to be selected every time. I'm looking for a way to force the selection to be made automatically and hidden. Did you have the same situation and solved this somehow?
Marking the issue closed, as this should solve it for OP too.
Comment #5
Rustan CreditAttribution: Rustan commentedI found how to always force a new revision to be created using the supplied hook from vbo:
Comment #6
Rustan CreditAttribution: Rustan commentedTurns out this only works for users with the "administer content" permission. Other users overwrite the last revision.
Comment #7
SseggembeMoses CreditAttribution: SseggembeMoses commentedHow about if you get the "field permissions module" and create a user role and give them permission to edit a particular field.
Also in the permissions page give the role this permission under the VBO " Execute Modify entity values "
Comment #8
Rustan CreditAttribution: Rustan commentedI tried using actions_permissions (was it this you meant?) that is part of VBO, set it to allow other users to "Execute Modify entity values", and it worked just the same as without actions_permissions activated. I tried giving other users all permissions that exist in actions_permissions but none have any effect on this issue, the last revision is overwritten instead of a new revision created.
It seems that others have problems with how VBO handles revisions as well, like this.
Comment #9
SseggembeMoses CreditAttribution: SseggembeMoses as a volunteer commentedSorry about that, I have tested it out with other users and it works fine, revisions are created as expected. Though you have to select " create revision"
Have you given other users access to permissions under "Revisioning" and also permission to edit content under " Node "?
Do you have the latest versions of Revisioning, Views, VBO and Workbench ?
Also under "PAGE SETTINGS" in your view, you can select "access" to "role" and then select the roles that can access this view.
It is really ironic if it works for me and it doesn't work for you, may be you are missing out something that is very trivial.
Comment #10
Rustan CreditAttribution: Rustan commentedThank you! It is very helpful to know it works for you, then there is something wrong in the configuration and not the code.
I am very confused as to what it can be though. I do not use workbench, but other things checked and ok. I'll have to continue digging and see what it can be.
Comment #11
SseggembeMoses CreditAttribution: SseggembeMoses as a volunteer commentedGood luck to you
Comment #12
Itangalo CreditAttribution: Itangalo commentedIt's been a while since I did Drupal coding, so this patch needs testing. (I also just realized that I haven't created the patch in the proper way -- this is just a simple diff.)
Still, I think this does the trick:
* When modifying nodes that by default are set to use revisions, revisions are created.
* When modifying nodes that not are set to use revisions by default, revisions are not created.
Needs testing:
* If "revisions" field is included in the listed properties in the VBO, its setting should override the default setting.
* Nothing should be affected if the object being affected isn't a node.
Comment #13
Rustan CreditAttribution: Rustan commentedAwesome, thanks Johan!
Works great for me, but always creates a new revision on nodes where it is activated, ignoring any revisions settings in the vbo (revision setting is two-stage, select it and then select or not select one to be created).
Comment #14
Itangalo CreditAttribution: Itangalo commentedA somewhat better patch. Same code, comments improved.
EDIT: Oops, didn't see comment 13. So that bug is still present.
Comment #15
Itangalo CreditAttribution: Itangalo commentedThere – another check in the if statement, making sure that the default revision setting is only used if the 'revisions' property isn't checked in the VBO front end.
Verified:
* When modifying nodes that by default are set to use revisions, revisions are created.
* When modifying nodes that not are set to use revisions by default, revisions are not created.
* If "revisions" field is included in the listed properties, and is marked to be modified by the user, its setting overrides the default setting.
Needs testing:
* Nothing should be affected if the object being affected isn't a node.
Comment #16
Rustan CreditAttribution: Rustan commented#15 everything works as expected, great!
Comment #17
Ron Collins CreditAttribution: Ron Collins at Affinity Bridge commentedThe patch in #15 applies to vbo 3.3 but didn't solve the problem for me. Anyone else tried it on 3.3?
Comment #19
joelpittetThis has been committed to -dev, thank you @Itangalo and all the others who helped.