Add permission to allow editing of the node body but not the webform settings

We won't be adding this feature, see my explanation of why we can't do this in #775072: Add 'edit webforms' permission for attached webforms.

Hey @joachim, sorry I never got back to this issue. I think you're right that we could add another permission on top of the existing node_access() checking, however this really doesn't seem to be a common request. If you're still interested in this (I know it was years ago), we could make a separate access callback instead of using node_access() directly. We're already doing this for results pages with webform_results_access(). However, I'd like to avoid adding actual additional permissions since the use-case seems to be limited. That way your add-on module would have a trivial task of just implementing hook_webform_update_access() (or whatever we call it).

I'm also interested in this feature.

Currently, I'm using the 'block functionality' to show the webform to visitors for specific content types. This allows me to prevent my clients to change the actual webform and still let them change the contents of the node. However, this is a limited solutions and I already came across a use case where I want to use a specific (node) field value in a webform.

Yepp, I went the block route for years for the very same reason and just started to question it today. I guess there's not much request for this yet because somehow it works. But it would work much better having additional permissions:

It really doesn't make much sense we need to create a separate node of a separate content type and embed that node as a block on a certain node only to prevent editors from editing those form components and settings – when we actually could just throw some webform components directly onto our desired node in the first place.

I posted this on another thread.

I have noticed this idea has not been answered. I agree with this post, currently today we installed webform and we noticed users had access to the webforms and it's fields. We thought it was an issue with domain access and webform but after looking into this, I'm guessing this is how the module was created. We would like the users to see the results of the webform but not allow them to create, modify or delete the webform and it's fields. If anyone has found a work around for this, it would be appreciated.

I have read through the threads carefully. Even though quicksketch thought that the original request was to edit the webform and NOT EDIT the node, I believe all the requests were for the opposite. I think this is a pretty common use case, where a user can edit the body and fields of the node, but because of the complexity of the webform, cannot edit the components or settings. Generally these take more care and knowledge to set up than the data in the node.

However, I would like to be able to support all 4 permutations of access. This patch introduces a new permission ('edit webform components') which, in addition to node_access('update') grants permission to the WEBFORM tab and its menu sub-paths. The EDIT tab is not altered. In addition, hook_webform_update_access has been added to override this access. In contrast to hook_webform_results_access, the update access hook REPLACES the built-in access. The implementation should return NULL to defer to other implementations or the built-in access, FALSE to definitely deny access, or TRUE to allow access if all other implementations consent.

Because of this, implementation of the hook must consider existing access to the node. An example in webform.api.php makes this clear.

Because the new permission is in addition to the node_access system, it should be granted to all authenticated users by default, in order to mimic today's functionality. Technically, it could be granted to anonymous users too, but I doubt there are any sites that allow anonymous users to edit nodes.

I struggled a bit with the description of the new permission, and arrived at:

Content authors: access and edit webform components and settings

Grants additional access to the webform components and settings to users who can edit the content. Generally an authenticated user permission.

If anyone can improve on this, please post a follow-up comment. Patch to follow.

Committed to 7.x-4.x and 8.x. 'drush udpatedb' required.

@DanChadwick Nice work! I've yet to actually test it, but your approach certainly seems sound and covers all the concerns, well done.

Regression: Patch #10 broke the e-mail form due to a copy/paste error in webform_menu(). Patch to follow.

Regression fix committed to 7.x-4.x and 8.x.

The access callback for 'webform/ajax/options/%webform_menu' has the wrong access arguments.
The attached patches fixes the issue for:

• 7.x-4.x (webform-add_permission_to_allow-1509424-17.patch)
• 8.x-4.x (webform-add_permission_to_allow-1509424-17-d8.patch)

Thanks! #17 committed to 7.x-4.x and 8.x.

This issue is cited in commit: Issue #1509424 by DanChadwick: Added permission to allow editing of the node body but not the webform settings and vice versa and was a part of the 7.x-4.2 release.

In this commit, there is an update in the .install file (7420) that grants the "edit webform components" permission to DRUPAL_AUTHENTICATED_RID -- which is all roles that are authenticated.

/**
 * Extend access to the WEBFORM tab to anyone who can access the node's EDIT tab.
 */
function webform_update_7420() {
  user_role_grant_permissions(DRUPAL_AUTHENTICATED_RID, array('edit webform components'));
}

In my case, this grants permissions to roles that shouldn't have it, namely authenticated users.

The issue is mitigated by the fact that authenticated users can't edit webforms. But, there is a real concern in my implementation (which effects over 1300 individual sites) that this conveys a message about authenticated users to my site admins that might result in those site admins granting additional permissions to authenticated users that they should not have.

I plan to create a patch in my implementation to revoke the permissions this update grants, but I wanted to bring it here for possible discussion. For me, this update makes an overreaching assumption about permission granting.

Anybody have thoughts?

@karenann -- Fortunately you are misunderstanding what the permission does. It is intended to be granted to all authenticated users.

The 'edit webform components' permission doesn't grant any access that the user doesn't already have. The absence of the permission revokes access to the webform components to those users who can otherwise edit the node form.

In other words, if you grant 'edit webform components' access to every user, even anonymous users, no one can do anything they couldn't already do before the patch.

If you revoke 'edit webform components' access to a user, then they can no longer edit webform components, even though they can edit the node itself (with the exception of uid 1, which is not subject to permissions). If you revoke this from all users, only uid 1 will be able to edit webform components.

I tried to make the description for the permission as clear as possible, but obviously it still is confusing. I would welcome a patch in a new issue to revise the text to make it even clearer.

Since MIT is running 1300 sites with webform, maybe now would be an excellent time to fund some webform development. :;

@DanChadwick -- Thanks for such a quick response!

No worries, it was clear what it does and there's no misunderstanding here.

And I want to be clear, I don't think anything was done incorrectly or short sightedly, not at all.

I might have a isolated situation in this instance. For us, we get that the granting of that permission does not allow anyone to do anything unless they have, say, "Node: Webform: Edit any content". Which is great! (thanks!)

The problem we have here is that when you have that many sites, and that many site admins, they might see that a given role can "edit webform components" and get frustrated that they can't. While you and I know it's because they need additional permissions, they don't. At the same time, we could have an admin that looks down the column and sees one single checkbox under the authenticated column and say "la dee da", let's check everything. (Side note, we have a custom module which allows us to hide/expose permissions to our admins, buffet-style)

Granted, we can't police everything and we can't save admins from themselves... I think I'm mostly just thinking publicly, wondering if anyone else has the same issue or ideas that I don't.

For us, I'm creating a custom patch that suppresses the permission granting in update 7420 and, instead, grants the permissions in our install/upgrade script.

As for MIT's involvement, support, and funding. I have zero say on that but I can promise that I (and many others here) have actively and tireless campaigned for that and will continue to... (it is on my mind constantly!!!)

I know this is closed, and if I should comment elsewhere please direct me to that place.

Background: I have a site where access to edit content is granted very broadly at the permission level, and then that edit access is "siloed" to different areas through OG. As a result, a person with a role that has the "Webform: Edit any content" node permission can't actually edit any webform, rather just the ones with a relation to a group they're a member of. So, for us, this 'edit webform components' permission -- granted to the auth user role as usual -- means that a person might be able to edit a small handful of the site's webforms.

Use case: I need that hypothetical person to also be able to view results (and submissions) for that same small handful of webform nodes (which they are not necessarily the author of). Granting 'access all webform results' to a particular role is too broad, because then the user can see results for all webforms site-wide (instead of just the small handful). OG can "silo" node permissions by checking for relations between nodes and groups, but OG can't do the same for permissions defined by webform. Luckily, 'edit webform components' is slaved off of a node permission, so it works beautifully. On the other hand, 'access all webform results' isn't slaved off of "Webform: Edit any content" and therefore it isn't under OG's influence, so it cannot be used on our site. EDIT: I suppose the og_webform module would do what we need, but with no stable release and no release at all in 5 years, that doesn't seem like an option.

Question: What would be the harm in having the webform module behave such that a person who can 'edit webform components' for a particular node is automatically also granted access to view results and all submissions for that same node? If this were the case, our use case would already be a solved problem, as the OG siloing would successfully trickle all the way down to results viewing instead of just node editing and webform component editing. Now, I'm sure the argument against me is "someone who can edit the components shouldn't automatically be able to see submissions/results" to which I counter: "someone who can edit the components already can add their own email address to the E-mails tab and get at submission data that way, so also getting that same data by visiting node/%/webform-results is actually just an added convenience, nothing else". Unless I'm missing something :)