Problem/Motivation

As discussed in #3464704: Refine semantic of 'administer own $type registration' permission these permissions have a confused semantic about 'own': it refers here to (edit) access to the host, whereas in Drupal core and other registration permissions it refers to being the owner/registrant.

Proposed resolution

Use hook_requirements to block upgrading the module if those permissions are still in use, forcing sitebuilders to take action.

Remaining tasks

User interface changes

API changes

Data model changes

Comments

jonathanshaw created an issue. See original summary.

jonathanshaw’s picture

Status: Active » Postponed
Related issues: +#3479435: Create 'manage host' and 'administer host' permissions

Postponed on #3479435: Create 'manage host' and 'administer host' permissions as that provides the new permissions that should be used instead.

john.oltman’s picture

Removing permissions that are out in the wild is very difficult and requires deprecation. Meaning you can't just remove them - you have to deprecate them first, then remove them during a major release upgrade. Given that, let's set this aside for the purposes of #3464706: [META] Access & validation refactoring.

john.oltman’s picture

Category: Bug report » Task
jonathanshaw’s picture

Issue tags: +Major version only
jonathanshaw’s picture

Perhaps there's a case that if we want to deprecate these, the sooner we do it the better, especially if the path forward is not straightforward for some sites.

It's removing the permissions that has to wait for a major version, not deprecating them.

john.oltman’s picture

Ideally this would drop before we have to do any deprecations:

https://www.drupal.org/project/drupal/issues/2924785