The issue occurs due to the code in WebformElementBase.php
public function checkAccessRules($operation, array $element, AccountInterface $account = NULL) { ... // If #private, check that the current user can 'view any submission'. if (!empty($element['#private']) && !$webform->access('submission_view_any', $account)) { return FALSE; }
Since the user doesn't have the
submission_view_any
permission, the user does not have access. I just ran into this issue for the "Private" webform field attribute. Even though I have users with the ability to view results for the webform, they cannot view the Private field. The description for the element says this:Private elements are shown only to users with results access.
However, that doesn't seem to be the case in this circumstance, since they have results access, just not the broad
submission_view_any
access its looking for.Plus, the function even invokes
hook_webform_element_access()
, however, it does so after checking if the field is private and returning false in that case. So you cannot even use the hook to affect private field access.Can someone please help? I don't know how to give users access to the private fields I need them to see. Giving "submission_view_any" is too much, and then I'd have to revoke access to a bunch of things.
I'm going to mark this as Major for the reasons described above.
- @solideogloria opened merge request.
- Status changed to Needs review
almost 2 years ago 8:49pm 10 April 2023 I added some changes that allow private field access to be controlled by implementing the new
hook_webform_element_access_alter()
. I also added the hook to the webform.api.php file. The code in the hook example is roughly what I used to fix private field access to allow webform node owners to view/edit private fields on submissions for webform nodes they own.Whether or not such code should be added to the Webform Node submodule with
webform_node_webform_element_access_alter()
, I'm open to suggestions.To use the changes as a Composer patch, download the file here (don't use the hyperlink for Composer patches, as the contents of the patch will change anytime changes are pushed to the MR):
https://git.drupalcode.org/project/webform/-/merge_requests/319.patch
Save it to your project's patches folder with a name like
webform-m319.patch
.Then, add the patch to your Composer patches.
- Status changed to Closed: won't fix
almost 2 years ago 12:41am 2 June 2023 - 🇺🇸United States jrockowitz Brooklyn, NY
We cannot change the existing #private behavior without causing regressions for existing installations.
The patch can be used AS-IS for sites that want this behavior. A dedicated contributed module could be created.
- Status changed to Needs review
almost 2 years ago 2:59pm 2 June 2023 I think you should look at the changes. All the patch does is add a new hook so that users can modify access in a custom module. This doesn't actually change existing behavior on its own.
- 🇺🇸United States jrockowitz Brooklyn, NY
We can keep this open but I am very uncomfortable making any access control changes to the core Webform module.
- 🇨🇦Canada Liam Morland Ontario, CA 🇨🇦
Liam Morland → made their first commit to this issue’s fork.
- last update
over 1 year ago 535 pass - Status changed to Closed: won't fix
5 months ago 7:45pm 23 November 2024 - 🇺🇸United States jrockowitz Brooklyn, NY
I can't justify making any more changes to the Webform module's access controls.