When creating new webform nodes using the 2.6 release, I recieve the following error:
user warning: Duplicate entry '41-1' for key 1 query: INSERT INTO webform_roles (nid, rid) VALUES (41, 1) in /path_to_environment/sites/all/modules/webform/webform.module on line 496.

Looking through the code, I found a problem at the same line. When iterating $node->webform['roles'], $rid is always assigned 1 because that is the value (ON) of the checkbox for the role. To get the role ids, rid, you need to instead use the keys of the array.

Comments

tobiassjosten’s picture

StatusFileSize
new681 bytes

Here's a patch that solves the issue. Diffed against the 2.x branch.

tobiassjosten’s picture

Status: Active » Needs review

Oops! Forgot to change status.

tobiassjosten’s picture

Problem persists in newly released version 2.7 and this same patch applies cleanly to it as well.

djalloway’s picture

Status: Needs review » Active

I've reviewed your issue and this does not appear to be the case.
A clean install and thorough test reveals that there is no problem with Webform inserting role id's.

The values in the $node->webform['roles'] array consist of a numerically incrementing key and a value of the selected Role ID.
So the original code that pulls the Value from the Array is indeed correct.
Here is a variable dump of the $node->webform['roles'] array on my test webform where I have 6 roles assigned to the webform.

Array
(
    [0] => 1
    [1] => 2
    [2] => 3
    [3] => 4
    [4] => 5
    [5] => 6
)

So, I am not sure why you are receiving the error, but I doubt it is caused by buggy Webform code, it must be some other form of conflict.
Have tried testing on a clean install of Drupal + Webform and see if you get the same error?

tobiassjosten’s picture

I just set up a clean install and tried it out again. The problem, I found, arises when disabling "Submission access control", under Advanced options at 'settings/webform'. Then suddenly the array in $node->webform['roles'] looks something like this:

Array
(
    [1] => TRUE
    [2] => TRUE
)

Typecasting a boolean true to an integer with db_query() turns it into '1', so the same node receives role '1' multiple times, which clashes with the primary key.

This realization invalidates my patch so please disregard it. A patch for this problem should solve the issue of an invalid array before it's iterated to add roles. If no one beats me to it, I hope to come around to do that in a few days.

djalloway’s picture

In webform.module on Line 697.
When Webform Submission Control is disabled, the #access attribute in the form is set 0 (FALSE) which keeps the Role selection from rendering.
I believe this is where the $node->webform['roles'] array is losing it's values, as the #default_value attribute does not come into affect.

OnlineWD™’s picture

Subscribing

albert volkman’s picture

Subscribing

gpk’s picture

I can confirm that the "Disable Webform submission access control" setting seems to cause this problem. Also of possible relevance - I have FCKeditor enabled, have not tried disabling that to see if it makes any difference...

Using version 6.x-2.7 in Acquia Drupal 1.2.14 (Drupal 6.13).

El Bandito’s picture

Hi

I also have "Disable Webform submission access control" set.

Can anyone confirm the consequences of this error message ? Can I just ignore it ? Should I enable webform access control ?

Thanks

Dave

miggidy’s picture

Finally found this thread; thanks for tracking it down. I can confirm that this resolved my issue on Drupal 6.14, WebForm 2.7, with FCKEditor.

nick johnson’s picture

Piling on. This module rocks.

ogrady’s picture

Experiencing the same problem. Subscribing.

miraclestyle’s picture

Subscribing.

ogrady’s picture

What exactly resolved the issue for you?

quicksketch’s picture

Status: Active » Fixed
StatusFileSize
new733 bytes

Thanks everyone for the tip about needing to disable Webform Submission Access Control in order to reproduce. I've committed this patch to 3.x and tobiassjosten's patch from #1 to the 2.x branches.

quicksketch’s picture

StatusFileSize
new1.12 KB

Arg, looks like the patch to the 2.x version actually caused an API breakage (which causes are tests to fail). I've applied this patch which only does the role cleanup on node submission, not when calling node_save() directly.

Status: Fixed » Closed (fixed)

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

scott m. sanders’s picture

Version: 6.x-2.x-dev » 6.x-2.9

I'm getting this error when I preview, then save my webform config.

davidneedham’s picture

Status: Closed (fixed) » Active

I get this error whenever I create a new webform. I'm using 6.x-2.9 and Drupal 6.16.

quicksketch’s picture

Status: Active » Fixed

This is already fixed in CVS, we just need a 2.10 release.

Status: Fixed » Closed (fixed)

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

espirates’s picture

I get this issue too any news on if a 2.10 will be released ?

zhuber’s picture

I'm actually getting this issue still.

Info about the site:

  • Drupal core version 6.26
  • Webform version 6.x-3.x-dev

I was experiencing this issue with a stable version of Webform, so I updated it to the dev version. It is still throwing a duplicate key error:

Duplicate entry '9434-2' for key 'PRIMARY' query: INSERT INTO webform_roles (nid, rid) VALUES (9434, 2) in /sites/all/modules/contrib/webform/webform.module on line 1037.

Garry Egan’s picture

Any progress on this fix?

user warning: Duplicate entry '14-1' for key 'PRIMARY' query: INSERT INTO webform_roles (nid, rid) VALUES (14, 1) in /home/example/public_html/example.com/modules/webform/webform.module on line 1037.
user warning: Duplicate entry '14-2' for key 'PRIMARY' query: INSERT INTO webform_roles (nid, rid) VALUES (14, 2) in /home/example/public_html/example.com/modules/webform/webform.module on line 1037.

I see threads about patches, patches that don't work, patches that only work under certain conditions.

This is the time where someone writes: Go into webform.module and change THIS to THIS.

Help!

albert volkman’s picture

I don't believe the 2.x branch is still maintained. Is this still an issue for you with 6.x-3.x? If not, we need to leave this closed issue closed.