New or edited form fields not displayed on front-end when 'authenticated' user role is not present

Created on 7 March 2023, over 1 year ago
Updated 30 July 2023, over 1 year ago

I added a few new fields to an existing webform, and the fields were not displaying on the front end. I checked the YAML source file, and all of the new field elements looked like this:

city:
'#type': textfield
'#title': City
'#access_create_roles': { }
'#access_update_roles': { }
'#access_view_roles': { }
state:
'#type': select
'#title': State
'#options': state_names
'#access_create_roles': { }
'#access_update_roles': { }
'#access_view_roles': { }

Why are those "#access_" items in the YAML? I did not specifically set any such access rules for those elements, and the Access tab for each of those elements looks exactly like that of the elements that are correctly displaying. I deleted them manually from the YAML and they now show up on the front-end, but that is jot a permanent fix, I presume.

🐛 Bug report
Status

Closed: duplicate

Version

6.2

Component

Code

Created by

🇺🇸United States hockey2112

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @hockey2112
  • 🇺🇸United States jrockowitz Brooklyn, NY

    I think there is something wrong with your setup.

    Maybe JavaScript is not working.

    Maybe custom code or another module is causing the problem

  • Status changed to Closed: works as designed over 1 year ago
  • 🇺🇸United States hockey2112

    You are absolutely correct. My anonymous and authenticated user roles were missing from my database. My best guess is that something went wrong when uninstalling a module (probably the BAT and BEE modules). Apologies for any confusion.

  • Status changed to Active over 1 year ago
  • 🇳🇱Netherlands Dimiter

    I would like to re-open this issue, as I am experiencing the same issue as reported by @hockey2112. Hopefully I am able to provide some more context and steps to reproduce the issue.

    Environment

    I am using Drupal 10.1.1, PHP 8.2.5 and Webform 6.2@beta6 . The site (work in progress) currently does not have any custom module-code apart from a single unrelated block plugin. There is a custom theme, but that does not contain any logic and only supplies override templates and libraries with custom css/js. Theme debug shows the webform fields being rendered with the templates from the stable9 theme from D10 core. I have only enabled the webform and webform_ui (sub)modules. No patches have been applied to the webform module, and only a limited number of other contrib modules (unrelated to webform functionality) is present.

    Steps to reproduce

    - Start with a minimal Drupal installation using the version numbers described above.
    - Log in as an Administrator user and perform all steps below as admin.
    - Install and enable the Webform 6.2-beta6 module and the webform_ui module
    - Navigate to admin/structure/webform , there should be a 'Contact' webform created by default
    - View (or 'Test') the Contact webform, and confirm the 'Your Name', 'Your Email', 'Subject' and 'Message' fields are present, as well as the 'send message' button.
    - Go to the 'Export' tab, and confirm the configuration for the 'name' field element looks as follows:

    elements: |
      name:
        '#title': 'Your Name'
        '#type': textfield
        '#required': true
        '#default_value': '[current-user:display-name]'
    

    - Go to the 'Build' tab, and edit the 'Your name' field
    - Change the title to something else (e.g. 'My name'), save the element and then save the form.
    - Go to the 'View' or 'Test' tab, and notice the changed field is missing.
    - Go to the 'Export' tab, and notice the configuration for the field includes more changes than the ones made above:

    elements: |-
      name:
        '#type': textfield
        '#title': 'My Name'
        '#required': true
        '#default_value': '[current-user:display-name]'
        '#format_items': comma
        '#access_create_roles':
          - anonymous
        '#access_update_roles':
          - anonymous
        '#access_view_roles':
          - anonymous
  • 🇳🇱Netherlands Dimiter

    After a day of thinking and researching, I can confirm that it happens to be exactly the same case as reported initially by @hockey2112 : On my environment, the 'authenticated' role was missing. After restoring the authenticated role from git history, creating or editing webforms works again as expected.

    I understand that this is an edge-case that won't occur on all installations, but I still believe it is a valid bug that should be fixed.

    The question why the authenticated role is not present on all installations, is something outside of the scope of the webform module's responsibility. In @hockey2112's case it might have been a different module's uninstall hook, in my case it was 'simple' developer malfunction (Apparently I had deleted the user.role.authenticated.yml file and imported the configuration afterwards, resulting in deleting the authenticated role).

    However, the bug that remains is that if the authenticated user role is missing, newly added or edited webform fields won't appear in the view or test tab when logged in as root/admin/super-user/uid:1 (very likely to happen for all logged-in users, but I only tested/confirmed this for the Administrator role). There is no visible error, no validation that fails and nothing in the logs when this occurs, making it a very difficult problem to debug.

    Possible solutions might include logging an error in the logs (e.g. when the form and/or element is saved), preventing the form from being saved by adding some validation that fails when the authenticated role is not present, adding checks in the module code to verify the existence of the authenticated role before it is being checked, or instead of querying the authenticated role adding fallbacks to check if the current user has permissions to create new form submissions, even if the user does not have the 'authenticated' role.

    (I didn't change the original issue summary, but feel free to do so based on the new findings. I did try to make the issue title reflect the actual bug more)

  • Are no other features in Drupal broken without this essential role?

  • 🇮🇹Italy apaderno Brescia, 🇮🇹
  • 🇮🇹Italy apaderno Brescia, 🇮🇹

    For all those permissions that are only given to the Authenticated user role, there are many part of Drupal that will not work.

  • I feel this should be closed and a core issue opened, if one does not exist.

  • 🇮🇹Italy apaderno Brescia, 🇮🇹

    A default role that vanishes is not caused by this module.

    Could not this be caused by a module that added new permissions that are then assigned to the Authenticated user role, which is then deleted when the module is uninstalled? I have seen some reports about that happening.

  • Status changed to Closed: duplicate over 1 year ago
  • 🇳🇱Netherlands Dimiter

    As noted by @cilefen, I've created a Core issue as suggested: #3378038 - Anonymous and Authenticated roles are deletable 🐛 Anonymous and Authenticated roles are deletable Active .

Production build 0.71.5 2024