When a user creates a service using the "simple service" workflow, it results in the creation of host/intercept configs and dial/bind policies. When a user deletes a service, it currently deletes only the service. Leaving the auto-created configs and policies around as orphans.
In the delete confirmation dialog, we could list related resources and offer users the option to also delete them by via checkbox option.
The ziti controller API supports finding related entities in both directions. For example, when trying to delete Service D, you can get a list of service policies that include Service D. Then the console can get a list of services that each service policy includes. This way, the console can display to the user that policy X is safe to delete because it only includes service D, while policy Y is not safe to delete (and perhaps shouldn’t be in the list) because it includes services other than the one being deleted (D).
When a user creates a service using the "simple service" workflow, it results in the creation of host/intercept configs and dial/bind policies. When a user deletes a service, it currently deletes only the service. Leaving the auto-created configs and policies around as orphans.
In the delete confirmation dialog, we could list related resources and offer users the option to also delete them by via checkbox option.
The ziti controller API supports finding related entities in both directions. For example, when trying to delete Service D, you can get a list of service policies that include Service D. Then the console can get a list of services that each service policy includes. This way, the console can display to the user that policy X is safe to delete because it only includes service D, while policy Y is not safe to delete (and perhaps shouldn’t be in the list) because it includes services other than the one being deleted (D).