I added a new required taxonomy field to a content type on Drupal 6.13 site yesterday. I have the Revisions and Diff modules enabled. I didn't instruct VBO to do anything in particular concerning revisions. I used VBO to set the new taxonomy field to my "default" value. All went well, but today I noticed the following issue:

All nodes that previously had at least one existing revision now show the last revision as made by me. It also shows the time of the change as when I ran the VBO job. If I Diff the revisions I see the addition of the taxonomy value, but I also see the changes made in the previous revision made by last person to revise the node.

Note that nodes that previously had no revisions don't note my changes (i.e., There is no revisions tab. This behavior is fine by me).

This merging of the previous revision with the change made by VBO and attributing both to me is causing confusion on the site, as the site has several dozen node editors. It also makes it impossible to correctly attribute the last change to the node, and makes the Views report I have on node changes irrelevant for the time being.

Why did VBO:
1) Record revision changes only on nodes with previous revisions? This is inconsistent.
2) Merge the revision with the previous revision?
3) Attribute both changes (as merged) to me?

I have a test site and can reproduce the problem.

Thanks,
Mike Hays

Comments

infojunkie’s picture

infojunkie
Location Vancouver
commented

After trying out your scenario, I found that the "Modify node taxonomy terms" action does *not* create a new revision. Instead, the taxonomy changes are considered to be part of the latest existing revision. Can you confirm this behaviour?

It seems that any action applied with VBO does not cause a new revision to be created.

Would you agree that if the option "Create new revision" is selected on a certain content type, VBO should always create a new revision for nodes of that type?

dogbertdp’s picture

dogbertdp commented

@kratib, that is the behavior. I tested taxonomy changes with both "Add the selected terms" and "Replace terms within same vocabulary". Both fold that change into the latest revision.

I have not seen VBO create new distinct revisions.

To answer your last question, under no conditions do I think that VBO should essentially "hijack" a current revision. If it creates a revision it needs to be distinct for that change only. Also, if it creates revisions for a content type that has the option "Create new revision" selected, it should create a revision for all modified articles, not just those with previous revisions already. Also, ideally VBO could be configured to not create a revision at all. I hope this is possible, even if it needed to be configured globally for VBO and not on a per Views basis. Let me explain why:

I generally use VBO to fix taxonomy changes for an entire content type or multiple content types. For example, perhaps I have the terms "abc", "xyz", "foo", and "bar". I decide that "foo" and "bar" should really be together, so I add a new term "foobar" and then I use VBO to change "foo" to "foobar" and "bar" to "foobar". Then I delete the terms "foo" and "bar". Reverting these changes would create problems since the previous taxonomy terms don't exist anymore, especially if I rely on the taxonomy for other critical functions on the site. This could even cause articles to go missing. So I would prefer to not create a revision in this case. This is one reason I would want to prevent revision creation, I have others specific to my site which has a large editor base. I see VBO as housekeeping, not really a traditional article edit, so expect no revisions.

Thoughts?

Thanks,
Mike

infojunkie’s picture

infojunkie
Location Vancouver
commented

I agree that VBO should let the admin decide whether or not to create new revisions - and do the right thing either way. I'll be looking at that bug soon.

dogbertdp’s picture

dogbertdp commented

Thanks. VBO is an excellent tool.

infojunkie’s picture

infojunkie
Location Vancouver
commented
Version: 6.x-1.8 » 6.x-1.x-dev

I committed a fix that automatically creates a new revision when VBO acts on nodes that require them. Please try the latest dev (12 hours from now) and let me know if that works on your side.

Regarding the option to avoid creating a new revision *and* to avoid merging the VBO changes into the current revision, I have a conceptual problem that I hope you can help me resolve. When VBO modifies a node that already has one or more revisions, we obviously expect the current revision to contain the changes made by VBO. Therefore, when you open the "Revisions" tab, the current revision will necessarily show the values as changed by VBO. But the earlier revision cannot contain those values. So in effect the changes made by VBO have to be merged into the current revision. What's more, in your taxonomy scenario above, even if you performed those changes by manually editing the node, then editing the taxonomy, your old revisions would no longer be valid since the terms would have been erased.

What I'm trying to say is that the only behaviour that makes sense for VBO is to create a new revision when the content type requires it.

infojunkie’s picture

infojunkie
Location Vancouver
commented
Status: Active » Fixed

Fixed until we resume the discussion with OP.

Status: Fixed » Closed (fixed)

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

ayesh’s picture

ayesh commented

May be a dumb question but how can I avoid creating a new revision automatically ?
I have Revisioning module and new revisions are in pending status. So changes won't affect. If there's a way to modify taxonomy terms without creating a new revision, it'd be useful.