Defining the Destroyer

The ABPersonalDataDestroyer class implements the PersonalDataDestroyer interface and provides methods that determine how a destruction request is carried out. The class provides methods that are called by the PersonalDataDestructionAPI web service and its work queues.

A personal data destruction request to delete a contact by AddressBookUID corresponds in ContactManager to one ABContact with a single LinkID value. The method translateABUIDToPublicIDs finds the PublicID value of the contact and returns it to the web service, which creates a PersonalDataContactDestructionRequest. This personal data destruction request enables the work queue to make a destroyContact method call to delete the contact by PublicID when the work item is processed.

If a personal data destruction request specifies deleting a contact by PublicID, ContactManager can directly use the PublicID to delete the ABContact object.

The following two methods are the primary Destroyer methods used by the web service.

translateABUIDToPublicIDs

This public method overrides the PersonalDataDestroyer interface method translateABUIDtoPublicIDs. It finds the ABContact with a LinkID that is the same as the specified AddressBookUID and returns the contact’s PublicID value.

The method is called by the web service PersonalDataDestructionAPI. The web service uses the method to determine if an AddressBookUID exists and to get the PublicID if the original destruction request was specified by AddressBookUID.

destroyContact by Destruction Request

This public method overrides the PersonalDataDestroyer interface method destroyContact. It is the main entry point for destroying contacts.

Note: The PersonalDataContactDestructionWorkQueue class calls this method when it processes a work item. The class calls PersonalDataDestructionController.destroyContact(contactPurgeRequest).

This method takes a PersonalDataDestructionRequest and finds the corresponding ABContact by PublicID.

Once the ABContact is found, a call to the PersonalDataDestruction plugin is made to determine whether the Contact can be purged.

  • If the result of the plugin call is MUST_NOT_DESTROY, the request is not processed for destruction. The reason is logged in the DATA_DESTRUCTION_REQUEST logger and the Destroyer returns the status ContactDestructionStatus.TC_NOTDESTROYED.
  • If the result of the plugin call is MAY_DESTROY or MUST_DESTROY, the request is processed for destruction and destroyContact(contact) is invoked.
    • If the purge is successful the Destroyer must return the status ContactDestructionStatus.TC_COMPLETED.
    • If there is a purge error, the Destroyer must return the status ContactDestructionStatus.TC_MANUALINTERVENTIONREQUIRED and log the error or exception in the DATA_DESTRUCTION_REQUEST logger.
    Note: The notifyDataProtectionOfficer method uses the error log level if there is a purge error. Otherwise it just uses the info log level.

It is possible that the contact was previously purged and cannot be found. For example, a previous PersonalDataDestructionRequest resulted in the ABContact being purged. In that case, the method returns ContactDestructionStatus.TC_COMPLETED.

See also