Akonadi Trashhandling

End of February I attended the annual pim meeting in osnabrück for the first time. There I started the akonadi trashhandling, which I need for MindMirror. The idea is to have a uniform way of handling trashed/deleted items in akonadi.

The general idea is to have to ways to separate trash from you normal items:

  • Mark them as trash but keep them in the same akonadi collection:
    This would i.e. allow a resource to map the deleted flag to i.e. the imap deleted flag.
    Of course, if the resource doesn’t support that, all items will remain visible for remote locations (i.e. gmail).
  • Mark them as trash and move them to a separate collection:
    This can be configured on a per resource basis, and allows to collect trash in i.e. another resource.
    This allows that trash is effectively hidden also to synchronised resources, but the downside is that your trash is not available on remote locations (except if you use another resource with sync as trash location).

Of course it is up to the application to use either way, but it should be quite easy to add trash support to applications, including standard actions to move to trash and restore from trash.

Heres what it consists of and what it can do for you(developers):

Marks an entity as trash with the EntityDeletedAttribute and moves it to a configured trash collection (if configured).

The default behaviour is to move the item to the trash collection which is configured in TrashSettings. If this trash collection is not available, the entity is kept in place.

All sub entites of a collection which is marked as trash are also marked as trash, and get the parent collection of the collection which was marked as trash as restore collection. This ensures that it is possible to restore items from trash, which were originally moved to trash together with the parent collection.

The job has also an option to automatically delete items which are already marked as trash.

Restore the entity from the trash collection to the original collection and remove the EntityDeletedAttribute.

By default the RestoreJob tries to move the entity back to the original location, which is saved in the EntityDeletedAttribute.
If this collection is not available anymore, it tries the original resource root as fallback, if also not available it aborts.

For this case it is possible to configure a special restore collection on the job, to which the item is restored.

If the move was successful the EntityDeletedAttribute is removed from the entity (and from all subentities).

Marks the entity as deleted and stores the restore collection/resource.
Resources could map this flag to an appropriate flag as the MarkAsDeleted flag in IMAP.

Store a trashcollection for a resource.

In the future further trash related settings, as the time before the janitor agent deletes items could be stored here.

TODO: atm. the settings are never removed. Even if the configured resource or trash collection is removed (not sure if this is ever done).

Either shows all items with the EntityDeletedAttribute or hides all entities with the EntityDeletedAttribute.
It is using a KRecursiveProxyModel, so also trash items which are in a non trash collection are shown in the trash.

Provides 6 standard actions:

  • MoveItemToTrash
  • MoveCollectionToTrash
  • RestoreItemFromTrash
  • RestoreCollectionFromTrash
  • MoveToTrashRestoreCollection
  • MoveToTrashRestoreItem

While the first 4 are trivial, the last two provide a single action, which changes its behaviour depending if the EntityDeletedAttribute is set or not. As it doesn’t make sense to restore entites which are not in trash or move entities to trash which are in trash, I believe it is the most common usecase and what I use myself.
All new actions need the EntityDeletedAttribute fetched in order to work properly.
I had to add some bits to the internal structure of the standardactionmanager to make it possible to change description/icon/etc. for a single action, everything existing should continue to work as expected though.

Trash Janitor Agent (TODO)
Goes trough all collections, and deletes items after a configured period of time, if they are marked as trash.
This configuration is in TrashSettings on a per resource basis, but could be overridden by a configuration in the EntityDeletedAttribute

This is not work in progress atm. but more a concept. I also don’t plan to add this anytime soon, so feel free to do it if you need it now, I’d be happy to help.


Author: cmollekopf

Christian Mollekopf is an open source software enthusiast with a special interest in personal organization tools. He started to contribute actively to KDE in 2008 and currently works for Kolab Systems leading the development for the next generation desktop client.

One thought on “Akonadi Trashhandling”

  1. Just a comment on th janitor agent: this is something which will be useful for a lot of cases, not just deleting old trashed items.
    E.g. taking over the expire functionality in KMail, which can also move messages of a certain age to a new folder, etc.

    A generic Janitor agent would make a great addition to the PIM runtime module and is great base idea for a GSoC project (e.g. for next year’s occurence if nobody starts creating one until then)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s