Problem/Motivation

It is currently possible to override of the uuid key in configuration entities. However this is problematic because the configuration importer needs to detect configuration renames, recreates and deletes using the uuid key and this is hardcoded because the module that supplies the configuration entity type might not yet be installed.

Proposed resolution

Ensure that the uuidKey is uuid.

Remaining tasks

Write patch with tests

User interface changes

None

API changes

Restrict uuidKey to only being uuid.

Data model changes

None

Why is this an rc target?

If a configuration entity used an uuid key other than uuid it would break ConfigImporter.

Comments

alexpott created an issue. See original summary.

alexpott’s picture

Status: Active » Needs review
FileSize
4.43 KB

I think this is the simplest thing to do.

At the moment the UUID key is basically enforced through the constructor of the ConfigEntityType constructor but this patch hardens and tests the implementation.

Status: Needs review » Needs work

The last submitted patch, 2: 2604450-2.patch, failed testing.

The last submitted patch, 2: 2604450-2.patch, failed testing.

alexpott’s picture

Status: Needs work » Needs review
FileSize
665 bytes
4.37 KB

Doh...

tim.plunkett’s picture

Status: Needs review » Needs work

Ran these as test-only locally, they did not fail.

tim.plunkett’s picture

tim.plunkett’s picture

Priority: Major » Normal

\Drupal\Core\Entity\Entity::uuid() still hardcodes uuid and #2052083: EntityType::getKey() should be used instead of hardcoding id, status, weight, etc. won't change that, so why do we have \Drupal\Core\Entity\EntityStorageBase::$uuidKey at all? Unless the entity class also overrides that method...

Shouldn't we just hardcode this in all entities?

xjm’s picture

Issue tags: -rc target triage

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.