Problem/Motivation

In #2571235: [regression] Roles should depend on objects that are building the granted permissions @alexpott found out that a number of entity permissions are not in the module that is providing the entity. For instance the permission "administer views" is in the views_ui module and not in the views module.

Proposed resolution

Move entity permissions to the modules that are providing the entity.
The following permissions will be moved:

  1. The permission "administer actions" has been moved from the action module to the system module;
  2. The permissions "administer url aliases" and "create url aliases" have been moved from the path module to the path_alias module;
  3. The permission "administer views" has been moved from the views_ui module to the views module;
  4. For all fieldable entities: The permissions "administer ENTITY_TYPE fields", "administer ENTITY_TYPE form display" and "administer ENTITY_TYPE display" have been moved from the field_ui module to the field module.

Remaining tasks

Review patch
Commit patch

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

TBD

For the committer

The idea for this issue comes from @alexpott. Therefore he should get a commit credit for this issue.

Comments

daffie created an issue. See original summary.

daffie’s picture

Status: Active » Needs review
StatusFileSize
new3.77 KB

I did a search for who might be using Drupal\field_ui\FieldUiPermissions, and I could not find anybody. See: http://grep.xnddx.ru/search?text=FieldUiPermissions&filename=.
There is alraedy for all the moved permissions a lot of testing. Therefore no new testing added.

daffie’s picture

Issue summary: View changes
longwave’s picture

+++ b/core/modules/field/field.permissions.yml
similarity index 93%
rename from core/modules/field_ui/src/FieldUiPermissions.php

rename from core/modules/field_ui/src/FieldUiPermissions.php
rename to core/modules/field/src/FieldPermissions.php

Just in case someone is using FieldUiPermissions, we could add class FieldUiPermissions extends FieldPermissions {} with a trigger_error() deprecation if the class is loaded?

alexpott’s picture

FWIW I'm not sure about this. It's really tricky. From a UI perspective it's not great to have these permissions around when the corresponding UI module is not available.

alexpott’s picture

A bit more on #5. For example, if administer actions move to system you'd expect if you tick that box on the permissions form a UI would become available. But it won't. You'll need to install the actions module.

I think this might be a won't fix... and something that the JSON API module needs to deal with. I.e. it needs to create an missing permissions if they are resources that require permissions that don't exist.

OR... we need new permissions for the entities.... but that's another can or worms.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

stephencamilo’s picture

Status: Needs review » Closed (won't fix)
andypost’s picture

Status: Closed (won't fix) » Needs review

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

needs-review-queue-bot’s picture

Status: Needs review » Needs work
StatusFileSize
new143 bytes

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

macsim’s picture

+1 on #5
I don't see a reason to have the "administer views" permission available if the Views UI module is disabled nor the "administer ENTITY_TYPE fields" when Field UI is disabled.

catch’s picture

Priority: Critical » Normal

Yeah I think these permissions were added to the UI modules for a reason. Reducing the priority here.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.