In the website administrator menu bar, click on People and then on the PERMISSIONS tab at the top-right of the screen, shown as follows:

Permissions are all about "who may do this action" or "who may access this content". It goes around what various users are permitted to do or not permitted to do.

Carefully read the paragraph at the top of the page regarding permissions, giving special attention to the closing sentence. Take this information to heart and let it guide your decision-making when assigning roles and responsibilities:

Scrolling down to the bottom of the page we find a heading for Webform with several permissions listed.

By default, no authenticated (that is, logged in) user may create or change Webforms, nor access submitted data, not even their own.

Reading the text under the various permission labels, we notice that anonymous users are completely banned from most activities.

For the purposes of later experimentation, let's permit authenticated users to access and alter their own submissions after the fact by granting them authority to Access own Webform submissions and Edit own webform submissions by checking the corresponding boxes in the Authenticated User column and then clicking on the Save Permissions button, as shown in the following screenshot:

Scrolling halfway back up the page so we are able to view the list of permissions under the Node heading, we find several more Webform permissions. The permissions listed here are focused on Webform as a Drupal content type, in contrast to the permissions we looked at previously which concerned themselves more with Webform data.

Looking at the options here, we can readily see that it is possible to create a user role that can create and delete its own Webforms, but cannot edit or delete Webforms created by a different role. With careful planning we can create very hierarchical structures in terms of user roles and their corresponding permissions.

Programmed into Webform (and all other facets of Drupal) are several checks to determine whether a user is authorized to carry out a requested action or view requested content. If the user or role permissions are not set, the requested action is ignored and an error message output is displayed on the screen.

By checking the boxes for authenticated users as we did previously, we are allowing authenticated users to return to forms that they previously submitted and make alterations to the submitted data. They will not, however, be able to delete their submission because the Delete own webform submissions permission is not checked.

We must be very careful when assigning permissions. If we were to accidentally check the box Access all webform results for authenticated users, then every registered user of our site would be entitled to download the data entered by every person who has submitted information on any and every Webform across our site. That is probably not a very good idea!

Drupal is, in general, a security conscious environment. Users of the site are, on first principle, denied authority on most activities and resources until fully authorized to them by the website administrator. The philosophy of 'Safety First' applies also to contributed modules such as Webform.

Why is this important? Well, just as we expect other websites to safeguard our personal information, so will our end users expect us to treat their submitted information with utmost circumspection. There is a large measure of implied trust on the part of anyone who submits information to a website. That trust may not be violated if we expect to retain our integrity and reputation.

Management of user roles and permissions can become quite a complicated task, depending on the size and scope of your web application. For more information on creating and managing user accounts and user roles, visit the following documentation web pages of drupal.org:

Roles: http://drupal.org/getting-started/6/admin/user/roles

Accounts and roles: http://drupal.org/node/22284