Fun fact about config system: deleting any config also deletes all configs which dependent on it.
So, if you delete a field that's mapped, the entire mapping gets deleted.
This is not the behavior we want.
What we would like is (at least):
* When deleting a field, notify admin that it's in use by a mapping
** Optionally admins from being allowed to delete a field that's in use by a mapping
* If a field has been deleted or is otherwise missing, mark the field as broken on the mapping but don't destroy the mapping altogether
* In the UI, flag the mapping as problematic (similar to how rules calls out errors)
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | salesforce-config_dependencies-2919376-8.patch | 23.49 KB | aaronbauman |
Comments
Comment #2
jonnyeom commentedI believe that having field-level dependencies does make sense. We just have to make sure the mapping does not depend on any field that we are about to delete.
A similar situation can be seen with views and its dependencies.
One problem I am seeing is that mappings are not successfully removing field dependencies, even when I unmap a certain drupal field.
Steps to Reproduce:
1. Map a Drupal field > This will make this field a dependency.
2. Unmap that field.
3. That field will still remain a dependency, and I will have to manually delete it from the config.
Thoughts?
Comment #3
aaronbaumanWhat I observed is that, when a dependent field was deleted, the entire mapping was also deleted.
If we can figure out how to get around that, I'm happy to restore field dependencies.
Comment #4
aaronbaumanHard dependencies on fields have been removed for the time being.
Changing title and description to reflect discussion
Comment #6
aaronbaumanPR open over on github: https://github.com/messageagency/sfd8/pull/8
This will probably only get into 4.x since it includes some minor but non-trivial API changes.
Comment #8
aaronbaumanComment #10
aaronbauman