Problem/Motivation

Currently the isReadOnly Method does not differentiate between a read only field and a computed field.

I am trying to copy all field values from one entity to another and failing miserably. As the related issues note, there's not really a set understanding of what isReadOnly() even returns but when I look at what is actually setReadOnly then those fields really shouldn't be changed so it would make sense to just skip fields that isReadOnly() except DataDefinition::isReadOnly falls back to computed if read only is not explicitly set so computed fields like path will appear like "read only" when they are not. The same bug of hurt applies to the pathauto property because, again, this is at the very root of the typed data hierarchy.

Proposed resolution

The sensible route would be to add setReadOnly(FALSE) to path_entity_field_info but I have no idea what havoc that will play with backwards compatibility.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Comments

Charlie ChX Negyesi created an issue. See original summary.

hchonov’s picture

hchonov
Primary language Bulgarian
Location Burgas
commented

I guess that starting Drupal 9 we could fix that and prevent read only fields from being changed after they have been populated once.

ghost of drupal past’s picture

ghost of drupal past
he/him
commented
Title: Path field isReadonly TRUE despite it's not » Path field (and pathauto property) isReadonly TRUE despite it's not
Issue summary: View changes

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

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). 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.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now 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: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

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.

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.

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.

luke.stewart’s picture

luke.stewart commented
Issue summary: View changes
Issue tags: +Bug Smash Initiative

Issue of the day for BSI.

At the core is the question whether a computed field should be considered read only. This issue postulates that it should not be the case.

There are two interpretations:
Read Only to be immutable. In which case a computed field would not met this criteria.
Read Only to mean - only read operations should be performed, but the result of a read operation might change (in the case of a calculated field).

Given the associated #2907629 it probably makes sense for a wider decision as to how to hand readOnly fields this would then inform whether computed fields should be considered readOnly which would then inform whether this should be considered a bug or a feature request.

Either way this probably needs an issue summary update.

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.