Establish requirements for uninstalling Quickstart modules

[bberndt-uaz]

What is the problem that we want to solve?

Some Quickstart modules leave behind configuration when they are uninstalled, so that they cannot be reinstalled without manually deleting the leftover configuration items. Other Quickstart modules can be uninstalled and reinstalled without issue.

This spike issue is intended for establishing requirements and processes for the uninstallation of Quickstart modules. We may need more than one set of requirements for all modules.

Open questions

1. Should we standardize the use of enforced dependencies? We have had issues with these in the past.
2. Are there cases where we could use config/optional instead of config/install?
3. Could recipes be helpful for these processes?
4. Should we block uninstallation of modules until all related content has been deleted?
5. We may need to define separate uninstall requirements for different types of modules depending on what configuration they create. What would these module categories be?

Related Quickstart issues

• AZ Global Footer can not be enabled without block class enabled and config does not delete when module is uninstalled. #1280
• Write tests to ensure all az_quickstart modules can be uninstalled and reinstalled. #1318
• AZ News: Allow az_news module to be uninstalled and then reinstalled without getting an error that the config is already present in the database. #1968
• Uninstall AZ Publication configuration when AZ Publication module is uninstalled. #3033
• Declare dependency of az_core on media or move field storage config for media fields to az_media or move config to optional folder. #4693

Related Drupal issues / change records

• Config dependencies can optionally be enforced
• Delete forum data on uninstall
• The Book module can be uninstalled with nodes with a book node type still existing
• Comment on [META-1] Installation and uninstallation of configuration provided by a module that belongs to another module's API