Problem/Motivation

Currently, when e.g. a media entity is being removed, if this entity was being referenced in a required field, upon editing the node referencing the entity, the required field will show the entity is missing...though the field will still be required and will fail validation when saving the node.

This is a usability issue because the content author might wish to edit something totally unrelated and will fail to save content due to this entity missing. Whether or not the editor will be able to sort out the validation issue is up in the air and something that would need to be addressed.

Proposed resolution

TBD

Remaining tasks

TBD

User interface changes

TBD

API changes

TBD

Data model changes

TBD

CommentFileSizeAuthor
#2 2940394-2.patch8.19 KBmarcoscano
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

anavarre created an issue. See original summary.

marcoscano’s picture

Status: Active » Needs review
FileSize
8.19 KB

Very rough POC, but serves for us to validate the approach.

Sam152’s picture

The approach in #2 is very close to what we do in entity_reference_integrity. If we do indeed want to protect entities from being deleted if they have associated references, perhaps it makes sense to bring across the associated services/tests etc too?

marcoscano’s picture

Thanks @Sam152 for pointing it out! In fact if this ends up moving forward, @Sam152 should also be credited because the patch in #2 is partly inspired in entity_reference_integrity's code.

However, I'm not sure if we should make this logic a broader API/Service, or just some internal logic constrained to ContentEntityDeleteForm. No strong opinions about this, but I'd lean towards keeping it internal for now. Tests should definitely be added, I can do that once there seems to be consensus on the approach.

Sam152’s picture

However, I'm not sure if we should make this logic a broader API/Service, or just some internal logic constrained to ContentEntityDeleteForm.

Are we confident that form is the only place we'll give users the option to delete something?

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now 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.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.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.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.

Lendude’s picture

Issue tags: +Bug Smash Initiative

Feels like a feature to me.

Also the the title/IS are talking about different things then the current patch. Would the idea be to 'allow saving incomplete entities' or 'not allowing deleting entities that would leave required fields empty'.

The IS talks about the first and the patch does the second right?

Either way, this feels like it should be optional.

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.

joachim’s picture

> Either way, this feels like it should be optional.

Agreed, which means that the problem stated in the IS still needs fixing as an entity validation issue, because the 'referenced entity got deleted' problem could still happen on a field that doesn't have this enabled.

It needs to happen at the validation constraint level, rather than the form level, because of things like REST and JSONAPI.

Referential integrity is a really complicated area, too!

For example, with the current patch, what happens if there is are references that point both ways, A <-> B? You'd never be able to delete either entity!

Thinking more widely, the behaviour in the patch is only one of a variety of behaviours that a site might want:

- prevent deletion of a referenced entity
- allow deletion, but clean up the value on the referencing entity (there's a module for that)
- allow deletion, and cascade the deletion to the referencing entity (there's a module for that too)

smustgrave’s picture

Status: Needs review » Needs work
Issue tags: +Needs issue summary update

Moving back to NW for an issue summary update.

Ready the current one (which was also mentioned before) it seems like a valid issue. If the entity is gone and the field is required it should still throw validation no?

Think one of the modules mentioned in #16 is https://www.drupal.org/project/entity_reference_purger which we use on a number of projects.

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.