Problem/Motivation
When using an Entity Reference field with a Form Display Select List and configured to use an Entity Reference Source Views, the original field value may be overridden when editing the node. This happens in some cases based on user permissions.
If the current user role/permissions don't allow access to the Entity Reference Source Views, the Select List is rendered empty. When the entity is saved - the field is saved as is, i.e. empty.
It may not be a problem if the field is required or if any custom Validation was applied to the field before submission (depending validations of course).
How to reproduce
-
Bootstrap a clear Drupal 8 & quick-start it using Umami
composer create-project drupal-composer/drupal-project:8.x-dev drupal_core_3038288 --stability dev --no-interaction
Next, execute the following command:php web/core/scripts/drupal quick-start demo_umami
This will start a built-in PHP webserver, install Drupal’s Umami profile to a SQLite database, and open your web browser to login to the new Drupal site. -
Add a new Views (admin/structure/views/add) Entity Reference Source for the Tags taxonomy vocabulary.
Fill-up the basic informations (name, machine_name, ...), then save and edit it. - Change the permission of this view to use the Access:Role | Administrator and finalize your Views by saving it.
- Edit the Tags field of Article (admin/structure/types/manage/article/fields/node.article.field_tags) to use our new Entity Reference Source as source .
- Update the Form Display of Tags (admin/structure/types/manage/article/form-display) field a Select Listdisplay.
-
Login as any Editor and access to the translation of
node/7/edit
. The field Tags is now empty.Originally, this entity - Skip the spirits with delicious mocktails - was tagged as Alcohol free article.
- Saving the entity will remove the previous Alcohol free value.
Proposed resolution
On Entity Reference field, when the source is a View page Entity Reference Source, we should check the source permission.
If the current user can't see the source, then we should disable the field & maybe add a description to the user why he can't update this field.
Remaining tasks
- Write a patch
- Write tests
User interface changes
TBD
API changes
TBD