Protect models from being accidentally deleted

Well, this is caused by the Drupal config management API and not a feature of ECA. We can't change that behaviour. The same would actually happen to views, just as an example. I've had this happening to me before too and I was hit by surprise.

The re-import piece, though, is strange. As we're having 2 config entities for each EVA model, maybe there is one left behind? You can find out more about this by going to /admin/config/development/configuration/single/export and trying to find out where that already existing ID is coming from.

Hi Jurgen, thanks very much for the guidance, I checked the configuration export and found no mention of the deleted ECA model. I tried importing it again and this time it worked. I'm not yet too familiar with Drupal's new (for me) way of handling config, I think maybe on cron the site's configuration was updated to reflect the removed ECA model from it.

I feel better knowing that I'm not alone in making the error of accidentally deleting critical parts of a site, I guess one day my first attempt at a Drupal module could be a "config_protect" module :)

This might be related:

I just added an existing field to a new contact form. A short while later, I decided there was a better way to do things, so I tried to delete the field. I also got a warning list of ECA models that would be deleted, but these models relate to other forms that use the same field. I wasn't deleting the field from all instances, just the one.

That's what happens with dependencies, when a model works with wildcards. So, if an ECA model is using e.g. an entity type and any of its bundles, and then has an action which depends on an entity field, then the dependency is on that field regardless of the bundle. The same applies to contact forms or other use cases.

I remember, when we implemented those dependencies, this was a concern because ECA can't tell if the dependency says "This field on all the bundles" or "This field on at least one of the bundles". We decided back then, that being on the safe side (i.e. field on all bundles) is more important and that the warning on screen helps users to avoid mistakes.

To circumvent that situation, the dependency in the ECA model needs to be removed, e.g. by being more specific about the entity bundle. After deleting a field from a bundle, then the wildcard dependency can be brought back to the ECA model.

This is helpful to know, I did not know that models that react to *any* bundle of an entity type will be slated for deletion if that field is removed from any of the bundles. It makes logical sense.

Could a conditional check if the bundle has the field prevent this? So a model can react to all bundles but always checks first if the bundle has the field before it tries to execute anything?

It's not about the execution of a model. It's about dependency management, i.e. when the ECA model gets saved, it determines its dependencies and stores them with the model. And when using wildcards, a dependency scope can be pretty broad.