Actions not applied to nodes created before installation of module
catfink - November 12, 2008 - 10:59
| Project: | Revision Moderation |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
I have set up the actions "enable revision moderation on node" and "disable revision moderation on node" to be triggered by changes of Workflow state. This works fine for nodes created after installation of the module, including those created before the actions were assigned, however the change is not applied on the trigger to nodes that were created before Revision Moderation was installed.
I would be happy to work on this myself, however as it would be My First Patch, it may take a wee while. Also, any pointers as to where I might find the source of the problem would be greatly appreciated!
#1
I can confirm this bug.
#2
Well, I have figured out the source of the problem. When new nodes are created, an entry is made for them in the revision_moderation table. However, this is not done for existing nodes. I manually added entries for the nodes that pre-dated installation of revision moderation and the actions are now triggered correctly. So I guess the solution is to insert existing nids into the table at installation.
Lots of reading required before I'm ready to submit a patch, though!
#3
Is the module expecting every single nid be present under revision_moderation table?
I did the following right after installing the module:
insert into revision_moderationselect nid, 0 from node;
so that the revision_moderation will contain all current nodes.
Can anyone confirm the validity of this workaround under different conditions?
#4
Same for Drupal 5. What can a dummy to to get the module work correctly for older nodes?
#5
Thanks for the sql workaround, mbrship. I can confirm it fixes it with Drupal 6.12 and revision moderation module version 6.x-1.0-alpha.
We installed the module in our dev environment before creating any content. We installed it in production after importing content, when we were sure it worked as we wanted to. Then we discovered this bug. It worked fine on new content. However, when we edited pre-existing content it didn't save the "new revisions in moderation" setting. We'd edit, check the box, save, and it would be unchecked next time we hit edit. Behind the scenes, the node wasn't magically added to the revision_moderation table in the database.
I fixed it with sql comands through the mysql utility.
First I backed up my database.
Then I inserted all of the existing nodes into revision_moderation :
insert into revision_moderation (nid, revision_moderation)select nid, 1 from node where nid not in (select nid from revision_moderation);
Since we have a lot of content, I inserted all nodes with revision moderation turned on and selectively turned off exceptions after. If you prefer to insert with all off, use
insert into revision_moderation (nid, revision_moderation)select nid, 0 from node where nid not in (select nid from revision_moderation);
The "where nid not in..." is optional. The nid's a primary key, so the database won't allow you to insert duplicates. However, SQL errors make our deployment team nervous, so I was more particular.
Once a node appears in the revision_moderation table, the "new revisions in moderation" checkbox will work.
I needed to set it to false for about 150 nodes, which I did with update statements. Here I fix all the nodes of a type we made called news:
update revision_moderation set revision_moderation = 0where nid in ( select nid from node where type='news');
I also knew everything created after a certain date should have it set to false. I could have done some fancy sql with node.created, but it was easier to eyeball it.
select nid, unix_timestamp(created) from node order by nid desc;
# Inspect results, notice the first nid after your cutoff date. In my case, that was nid 4000.
update revision_moderation set revision_moderation = 0
where nid >= YOUR_NID_HERE;
Thanks mbrship, you saved me a lot of time.
#6
Great description, tenaj, thanks!