No permission for 'create webform submission'

Because webforms are nodes, they follow the same access permissions used by all other node types. If you need to limit access to webforms, you should be using taxonomy_access, simple_access, or something similar. There aren't any permissions for "access story" or "access page" for the same reason. View access control can get a little more complicated than edit. Webform provides access control for submissions though, because it's the only module that knows what a webform submission is.

Adding a "view" access permission in webform_access is the same thing as installing taxonomy_access (or any other ACL module) which can prevent view access to nodes. Because webforms are nodes, if a user doesn't have access to view the node they won't be able to make a submission. I don't want to add an "access webforms" permission because there's nothing special about a webform node that would prevent existing solutions from working with it just the same as stories or pages.

A different request I've had before though is allowing access to the page but disabling the form: http://drupal.org/node/143448

Okay cool, we're on the same page here. The patch threw me off a bit.

I think what's likely to happen here is many users are going to want the ability to prevent submissions on a per-webform basis, just like users are apt to want access control on a per-node basis (hence the variety of ACL modules). However, since webform certainly isn't going to implement ACLs for webform submissions, I think it'd be helpful to make a basic per-node, per-role submission access. So instead of this being another permission on admin/user/access, this permission would be part of the node form for webforms. Then it would work for both your purposes in this issue and the request in http://drupal.org/node/143448.

I also like the idea of disabling the form rather than not displaying it at all, but perhaps we could make that an option at a later time.

Okay, some change-up here:

- I kept the behavior of needing to check roles to allow submit access. This is because I want users to be able to uncheck all roles and prevent further submission.
- Changed the update function to only add roles for anonymous and authenticated, since users of all other roles count as authenticated anyway.
- Update help text to describe the new access settings.
- Moved the access queries to hook_load().
- Create new theme_webform_view() function that returns the output that needs to be displayed.
- Added messages for "Submissions for this form are closed", "You must login or register to submit this form", and "You do not have permission to submit this form".
- By default if access is not allowed, the form is still displayed in a disabled mode.

I think this sets us up well for the patch to warn users of the submit limit. Where we can just pass in another argument to the theme function and print out a different message for that case.

I am having the same problem. I am fairly new to drupal and wanted to know how is it that i apply the patch?

http://drupal.org/patch/apply

This patch is up for review and after it's been okayed, I'll put it into the actual version. Please report any problem you have with the patch.

My primary concern is that the message displayed to the user implies that there's a form that they don't have access to, but it's not clear which form it means. In the screenshot attached for example, there are already 2 forms on the page.

So instead of the verbiage "submit this form", I simply changed it to "view this form". Implying that there's a form on this page that they currently cannot see. It helps with my particular reservation. The form is now hidden by default in this version.

As for the help text, cutting it down made things significantly less helpful for me. Webform has a target audience that's probably a little below the average Drupal user. Explaining the entire option from start to finish will hopefully keep me from having to answer support requests about access control.

Good work guys, this is a nice feature.

The patch in #13 works as advertised, but the messages aren't cleared away in some situations. For example, "You must login or register to view this form" appears at the top of the (now revealed and submittable) form after logging in via the sidebar login block.

So I reworked the patch to avoid using drupal_set_message(). I ended up removing the theme_webform_view() function and put that conditional logic in webform_view(), where $output is set to either the form, or one of the three messages.

I've tested this patch on the site I'm working on, on a fresh install of Drupal 5.7 with no other modules, with PHP4 and PHP5, and on two different hosts... every time the message shows up again after logging in. Weird, huh? This unanswered forum post describes the same thing: http://drupal.org/node/214389.

I noticed another small issue with the patch, the links in "You must login or register to view this form" don't always point to the right places. Line 925:

--- drupal_set_message(t('You must <a href="!login">login</a> or <a href="!register">register</a> to view this form.', array('!login' => 'user/login', '!register' => 'user/register')), 'error');
+++ drupal_set_message(t('You must <a href="!login">login</a> or <a href="!register">register</a> to view this form.', array('!login' => url('user/login'), '!register' => url('user/register'))), 'error');

When I apply this patch
- hidden fields show up to users (mentioning '(hidden)')
- things like %get[] %username don't return a value

i tried both the patches in #14 & #15 and got this error:

user warning: Table 'drupal5.webform_roles' doesn't exist query: SELECT rid FROM webform_roles WHERE nid = 2385 in /var/www/vhosts/goflyxc.com/httpdocs/includes/database.mysql.inc on line 172.

And there were no new permissions added too access control and it flagged my webforms as 'closed' for all users...

no....I didn't know I had to with patches (I'm rather new to patches).

I did run it now, it mentioned an update to be done. I ran it, no errors....but no change.....still no new permissions to access control....and anon users can still submit.

mdowsett: These permissions are not under Admin->Access Control, but are configured for each webform you create. Look on the webform|edit page for the settings.

(Running update.php in this case is needed because this patch adds a new database table.)

Ah! That'd be a better place for it!

However, there's no mention of any sort of restriction in the webform|edit|configuration page....what am I looking for?

There's nothing in the 'Form components' tab either but I would expect there to be.

@#22: On edit/configuration there should be a fieldset called "Webform access control" and the permissions are set there under "Roles that can submit this webform". I hope you are using the patch in #15 so we can see if anyone else encounters the same problem I have with the message persisting after logging in.

@#17: Hidden fields showing up can be fixed by applying the patch in http://drupal.org/node/247490.

Bingo! Got it.

I reinstalled a fresh copy of webform and then ran the #15 patch and all is good.

I think I ran #15 and didn't figure out where to look for the changes so I ran #14.

It would be nice to have the option to show anon users the form, but not allow them to fill it in or submit it so they know what they are missing! I am sure there are some forms that need to be kept private so it'd be best to make this an admin option - 'show the uneditable form to these roles'

I rerolled #13 for updates, broke out the messages into a second theme function and committed the patch. I also found a solution to the "Register or login" message showing up after logging in. This problem occurred when you visited a webform node to which you didn't have access to make a submission, then login using the Login block on the same page. The node's hook_view() was being fired once as an anonymous user (during the login) then again after successfully logging in. This resulted in the message being displayed to the user once as anonymous then again as a the registered user. While I'm tempted to blame this on a core bug somewhere, we can work around it in Webform.

The final code looks something like this:

  // When logging in using a form on the same page as a webform node, surpress
  // output messages so that they don't show up after the user has logged in.
  if (isset($_POST['op']) && isset($_POST['name']) && isset($_POST['pass'])) {
    $logging_in = TRUE;
  }

  if (!$preview && !$logging_in) {
    theme('webform_view_messages', $node, $teaser, $page, $submission_count, $limit_exceeded, $allowed_roles);
  }

Anyway, let's test out the latest code now that it's in CVS and reopen this issue for any bugs introduced. It seemed stable enough to go ahead and get it in there.