We're attempting to convert from using allowed_values to an allowed_values_function but we get a FieldUpdateForbiddenException from list_field_update_forbid(). It would be nice if this could be skipped if allowed_values_function is being used.

Issue fork drupal-2453195

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

dave reid’s picture

Status: Active » Needs review
StatusFileSize
new802 bytes
m.stenta’s picture

Version: 7.x-dev » 8.0.x-dev
Status: Needs review » Needs work

+1 for this.

The same code exists in Drupal 8 as well, so it should probably be fixed there first.

https://api.drupal.org/api/drupal/core!modules!field!field.api.php/funct...

m.stenta’s picture

Status: Needs work » Needs review
StatusFileSize
new972 bytes

Here's a patch for 8.0.x.

Status: Needs review » Needs work

The last submitted patch, 3: 2453195-no-exception-with-allowed-values-function-8x-3.patch, failed testing.

m.stenta’s picture

Oh... I also just found an issue with the original patch for 7.x. It should be checking $field['settings']['allowed_values_function'], but instead it is checking $field['allowed_values_function'].

Attached is a new patch for 7.x as well.

m.stenta’s picture

Status: Needs work » Needs review
StatusFileSize
new1 KB

Oops... can't check a field setting within empty(). Attached is a new 8.x patch.

Anonymous’s picture

Status: Needs review » Postponed

Shall we wait until php 5.5 has been updated to test bot? https://www.drupal.org/node/2296557
so we could use the method return value in function.

The last submitted patch, 3: 2453195-no-exception-with-allowed-values-function-8x-3.patch, failed testing.

mgifford’s picture

Status: Postponed » Needs review
Related issues: +#2296557: [policy] Require PHP 5.5

The last submitted patch, 5: 2453195-no-exception-with-allowed-values-function-7x-4.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 6: 2453195-no-exception-with-allowed-values-function-8x-5.patch, failed testing.

The last submitted patch, 5: 2453195-no-exception-with-allowed-values-function-7x-4.patch, failed testing.

isolate’s picture

Rerolling the patch for 7.x because it misses the ['settings'] array key.

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.

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

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.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.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.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.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.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.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

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

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

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

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

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

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should 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.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should 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.

Version: 9.5.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. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Status: Needs work » Postponed (maintainer needs more info)
Issue tags: +stale-issue-cleanup

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

chr.fritsch made their first commit to this issue’s fork.

chr.fritsch’s picture

Status: Postponed (maintainer needs more info) » Needs review

I have the same use case. I want to switch an existing field from having a static allow list to use the allowed_values_function

It was not possible because of this error:

In ConfigImportCommands.php line 290:

The import failed due to the following reasons:
Unerwarteter Fehler bei Operation update für field.storage.paragraph.field_layout: A list field 'field_layout' with existing data cannot have its keys changed.

alexpott’s picture

I think this makes sense. Atm you're allowed to change from having an allowed_values_function to a static list and it cannot validate that either.

I considered whether we should call the new allowed values function on all the values in the list with entity set to NULL but looking at example code we have in core gives me pause...

  /**
   * Implements callback_allowed_values_function().
   *
   * @todo This function violates the recommendation in options_allowed_values()
   *   to return a list of all possible values in any context when $items is
   *   NULL. Since this is not yet used for testing Views integration, that is
   *   alright for now. Fix this in https://www.drupal.org/node/2012130.
   *
   * @see options_allowed_values()
   */
  public static function dynamicValues(FieldStorageDefinitionInterface $definition, ?FieldableEntityInterface $entity = NULL, &$cacheable = NULL): array {
    $values = [];
    if (isset($entity)) {
      $cacheable = FALSE;
      $values = [
        $entity->label(),
        $entity->toUrl()->toString(),
        $entity->uuid(),
        $entity->bundle(),
      ];
    }
    // We need the values of the entity as keys.
    return array_combine($values, $values);
  }

I also thought about the implementation here - and originally I thought about checking is allowed_values was empty but after more consideration I think the current implementation is correct as the function takes precedence if both are set in options_allowed_values().

alexpott’s picture

smustgrave’s picture

Status: Needs review » Needs work
Issue tags: +stale-issue-cleanup

Just want to leave the tag for stats later. Especially if this one lands :)

Moving to NW for the tests.

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.