6.2 Breaks Webform Permissions

I have the same issue and it happened when I upgraded Webform to beta3 and Drupal core to 6.2. I have tried re-installing webform 6x2.0 Beta2 and still have the same permission problem which has me thinking that it may be the new core changes that are causing webform to break. Anybody else seeing this issue after core upgrading?

I'm also having the same problem after a clean install of Drupal 6.2 and Webform 6x2.0 Beta3 (using MySQL 5.0.51a, PHP 5.2.5 and IIS 6/0).

Ahh okay me too, looks like I'm not alone. I created another topic on the same issue, but I'll watch both anyway. I installed 6.2, then the latest version of webform. I didn't upgrade, just fresh installs.

In "common.inc" --> function "drupal_access_denied()" --> it's getting tripped up by the check...

if (empty($return) || $return == MENU_NOT_FOUND || $return == MENU_ACCESS_DENIED)

...because it's called by "system.admin.inc" --> function "system_batch_page()" because "$output" is FALSE after calling function "_batch_page()" because something in the statement...

if (isset($_REQUEST['id']) && $data = db_result(db_query("SELECT batch FROM {batch} WHERE bid = %d AND token = '%s'", $_REQUEST['id'], drupal_get_token($_REQUEST['id']))))

...isn't, and we know this is true because commenting out the "else { return FALSE; }" line in _batch_page() succeeds in getting the form submission response "The component positions and mandatory values have been updated." But this isn't true because nothing is really added, only the value of FALSE wasn't returned by _batch_page() to system_batch_page().

So the question is - is something breaking the value of 'id' so _batch_page() can't query and send a value to system_batch_page() to assign to $output so drupal_access_denied() isn't called?

I poked around all night, and couldn't really track anything down. I still have a webform running on 6.1 on another site, so I created the form components there (works fine with 6.1), then exported the table data to my database on the 6.2 site. All I had to do was change the "nid" field of each table record to the right node ID, and everything came up fine.

It's a hack, I know, but I needed the survey forms up and running by this morning in time for a press release going out. I had to disable viewing and editing of results entirely, as that runs up against this Access Denied bug, too. So the only results I can view are in my emails or directly accessing the database.

At any rate, I sure do hope we find out what changed between 6.1 and 6.2 that's thrown up this brick wall. There's nothing I can see in the webform beta3 changes that's even remotely related to the bug.

I also looked at the webform code last night in particular the API changes from core 6.1 to 6.2 that could affect webform and couldn't find anything that was obvious. I thought maybe I was on to something when I noticed that there was a similar issue for CAPTCHA here http://drupal.org/node/245216 that appears to have been fixed with some changes in the dev release. I haven't had time to investigate what they changed but it may be worth a look.

Yes, the 6.2 release broke permissions in webform, detailed in the Security Advisory (http://drupal.org/node/244637). I've been out of the country making a new release a little difficult at the present, but I hope to get a new one out shortly.

Is there a way to downgrade either drupal, or this module? I need to set something up by Monday!

I think its NOT really the best idea to downgrade Drupal but here you'll find 6.1:

http://drupal.org/node/3060/release

At least downgrading works.

I've applied the following patch to the 6.x version of Webform and a new release of Webform should be available from the Webform project page.

this patch is part of beta4? and that should fix the permissions-problems?
beta4 doesn't fix the problem for me and since I'm quite a newbe, I have no clue how to apply the patch...

The new release doesn't seem to have fixed it for me.. and I'm on a shared host with no SSH access, so I can't apply the patch.

Yes it should be in beta4. After upgrading, be sure to clear the caches at admin/settings/performance or run update.php. Even though there aren't any database changes, running update.php will clear the menu cache.

The new release (Webform 6.x-2.0-beta4) doesn't seem to have fixed it for me either, I have run update.php but attempting to edit a submission (even as admin) still throws:

Access denied

* warning: array_fill() [function.array-fill]: Number of elements must be positive in /home/dalriad/public_html/sustransglasgow/drupal/drupal-6/includes/database.inc on line 235.
* warning: implode() [function.implode]: Bad arguments. in /home/dalriad/public_html/sustransglasgow/drupal/drupal-6/includes/database.inc on line 235.
* warning: array_keys() [function.array-keys]: The first argument should be an array in /home/dalriad/public_html/sustransglasgow/drupal/drupal-6/modules/user/user.module on line 500.
* user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')' at line 1 query: SELECT p.perm FROM role r INNER JOIN permission p ON p.rid = r.rid WHERE r.rid IN () in /home/dalriad/public_html/sustransglasgow/drupal/drupal-6/modules/user/user.module on line 500.
* warning: Illegal offset type in isset or empty in /home/dalriad/public_html/sustransglasgow/drupal/drupal-6/modules/user/user.module on line 509.

You are not authorized to access this page.

Here's a patch that should correct the 6.2 problem. It's made against beta 4.

Thanks Gribnif! I missed those 3 in my hurry to get out another version. I've applied the patch and released beta 5.

Brilliant, thanks guys.

Thought it was still broke with my test webform, my BAD, somehow it was not "published"