Contact trash folder deprecated

This article provides some information about the trash folder in the contact module.

Contact trash handling

The trash for contacts is enabled by default. To deactivate it, set:

com.openexchange.contact.trashFolder.enabled=false

Below is an overview of the contact module’s behavior when the trash is activated. With this feature, we also introduced a hardDelete parameter, which bypasses the trashing mechanism. For more details, please see HTTP-API documentation

Contacts

  • Delete Contact: Moves the contact to the trash folder.
  • Delete Contact from Trash: Permanently deletes the contact.
  • Restore Contact: Moves the contact back to its original folder.
  • Restore Contact (if the original folder was deleted): Throws an error and moves the contact to the user’s standard folder.

Folder

  • Delete Folder: Contacts inside the deleted folder are moved to the trash.

Distribution list

  • Trashed Contact in a Distribution List: The contact remains in the list but is converted into an independent entry without references to the original contact.

Shared and public folders

  • Delete contact from a shared folder: The contact is moved to the trash folder of the folder's owner - it is the owner's data, and the owner's com.openexchange.contact.trashFolder.enabled setting decides whether it is trashed at all. The owner can restore it from there, and sees who deleted it as the contact's last modifier.
  • The user who deleted it usually has no access to the owner's trash folder. Their way back is the undo right after the deletion, or a restore addressed by the folder the contact was deleted from rather than by the trash folder: that restores exactly the contacts this user deleted from that folder, provided they may still create contacts in it.
  • Delete contact from a public folder: The contact is moved to the trash folder of the user who deleted it, since a public folder belongs to nobody in particular. The user can restore it from their own trash folder.
  • A contact the deleting user cannot read is deleted permanently instead. Deleting requires the delete permission alone, so a user who may read only their own contacts but delete anybody's would otherwise find somebody else's contact, readable in full, in their own trash folder.
  • In all cases, the user needs sufficient permission to delete the contact from the folder; no permission on the trash folder is required.
  • Cross-context address books follow the same rules: a contact deleted from an address book of another context stays in that context and goes into its owner's trash folder. A soft deletion from a public address book of another context is refused with CON-1009, since the deleting user has no trash folder there; delete it permanently instead.

CardDAV

  • Deleting a contact via CardDAV results in the contact being moved to the trash folder. Although the trash folder is not synced via CardDAV and the contact seems deleted in the client, the user still can restore the contact using the web UI.

Auto-delete trash folder

  • The contact trash folder can be auto-deleted after a configurable retention time (default 30 days). The auto-delete feature is enabled by default and can be deactivated by setting com.openexchange.contact.autodelete.enabled=false. The retention period can be changed by editing com.openexchange.contact.autodelete.retentionDays. This setting is exposed as JSlob via path io.ox/contacts//autodelete/retentiondays. By default the retention period can be changed by the user. To disable this, set protected: true for the path io.ox/contacts//autodelete/retentiondays.