When you have a customer with a site, and you
1) de-provision the site first, and
2) then try to de-provision the customer,
the ProvisioningEngine tries to de-provision the already de-provisioned site again and reports the status "deletion failed (import errors)".
This leads to an inconsistent state showing a site that still exists (because the deletion has failed), but the parent customer is de-provisioned successfully.
TODO:
1) if an empty SoapMassProv import file is applied to the OSV, the ProvisioningEngine should not give back an Error.
This will prevent the "deletion failed (import errors)" above.
2) After 1) is resolved, we also should try to detect immediately, that an object is de-provisioned and not to try to de-provision it again.
The best solution for 2) is to
2 a) synchronize recursively the actual status of the customer. Synchronization will detect that the Site is not provisioned anymore
2 b) and then rely on the non-provisioned status and skip the recursive de-provisioning of the child site.
When you have a customer with a site, and you 1) de-provision the site first, and 2) then try to de-provision the customer, the ProvisioningEngine tries to de-provision the already de-provisioned site again and reports the status "deletion failed (import errors)".
This leads to an inconsistent state showing a site that still exists (because the deletion has failed), but the parent customer is de-provisioned successfully.
TODO: 1) if an empty SoapMassProv import file is applied to the OSV, the ProvisioningEngine should not give back an Error. This will prevent the "deletion failed (import errors)" above. 2) After 1) is resolved, we also should try to detect immediately, that an object is de-provisioned and not to try to de-provision it again.
The best solution for 2) is to 2 a) synchronize recursively the actual status of the customer. Synchronization will detect that the Site is not provisioned anymore 2 b) and then rely on the non-provisioned status and skip the recursive de-provisioning of the child site.