Use proper machine names for permissions

Open on Drupal.org →

Created on 25 July 2014, over 10 years ago

Updated 6 June 2023, almost 2 years ago

Postponed

According to #2350615: [policy, no patch] What changes can be accepted during the Drupal 8 beta phase? → , this should be postponed to Drupal 9.
Changing the permission's machine name may require changes across many patches in order to make them consistent and it affects all contrib modules. It is essentially aesthetic.

Problem/Motivation

Drupal currently uses permission with machine names like access all views, and this is inconsistent with machine names found elsewhere in Drupal (where the convention is snake_case_with_underscores. To add to the confusion, some permissions have a mixture of spaces and underscores (such as permissions for particular node types, etc.).

Finally, as permissions are now defined in YAML (see #2295469: Add support for static permission definitions with *.permissions.yml → ), then permissions keys will need to be quoted, and will not match most other YAML keys as seen in Drupal configuration. #2328411: Convert all permissions to yml files and permission callbacks → is going to do the full conversion from hook_permission() to YAML, so once that's complete, this issue can be opened.

Proposed resolution

Enforce proper machine names like access_all_views instead of the machine names with spaces for all permissions.

Remaining tasks

Convert all permission names to machine names. While doing a find-and-replace, pay special attention to comments. Be sure to rename direct references to the permission machine name only, not references to the permission. An imaginary example of the correct way: "Be sure the user can access nodes by granting the access_nodes permission.":

Document the requirements for machine names.

User interface changes

None.

API changes

Permissions should only use machine names.

📌 Task

Status

Needs work

Version

11.0 🔥

Component

User system →

Last updated 1 day ago

Maintained by
🇺🇸United States @moshe weitzman
🇧🇪Belgium @kristiaanvandeneynde

Created by

🇺🇸United States geerlingguy

Live updates comments and jobs are added and updated live.

Needs tests
The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

Needs issue summary update
Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.

Incomplete comments

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Comment almost 2 years ago →
🇷🇺Russia Chi
Setting proper issues status per above conversation.
Comment almost 2 years ago →
🇷🇺Russia Chi
Can we establish a new policy for the permission names and apply it only to new permissions? Contributed modules and custom modules would benefit from it right now because they will not have to follow this weird naming convention.
Status changed to Needs review almost 2 years ago3:52pm 2 June 2023
Open in Jenkins → Open on Drupal.org →
Environment: PHP 8.2 & MySQL 8
last update almost 2 years ago
Patch Failed to Apply
Comment almost 2 years ago →
🇮🇳India chaitanyadessai Goa
Added patch
Status changed to Needs work almost 2 years ago4:21pm 2 June 2023
Comment almost 2 years ago →
🇺🇸United States smustgrave
#67 should be answered.
Comment almost 2 years ago →
🇺🇸United States volkswagenchick San Francisco Bay Area
Removing novice tag for now as it looks like a question of policy change was asked.
Comment almost 2 years ago →
🇨🇭Switzerland berdir Switzerland
Re #67, nobody is forced to do anything in contrib/custom code. permissions are just a string as far as core is concerned. It just happens to commonly use spaces instead of underscores.

The payment module for example uses a hierarchical permission names, separated by .: https://git.drupalcode.org/project/payment/-/blob/8.x-2.x/payment.permis...

IMHO, switching spaces to underscores without any other change like the patch in #68 is pretty pointless. It doesn't solve conflicts, it doesn't enable us to do anything we can't do now. The issue summary is also wrong in regards to YAML, spaces in keys do not need to be quoted as visible in those patches. If we were to introduce a change, it should be in context of #2919636: Design a better model for managing permissions → IMHO and for example move us toward a hierarchical permission system.

So I'm changing my opinion of #62 and am voting in favor of closing this as a duplicate of that ideas issue.

contrib.social Blog FAQ Discussions

Production build 0.71.5 2024