###############################################################################

      *****************        Hey! Welcome to the Kwoosh Workshop
     *******************       -----------------------------------
    *******  *****  *****
   ********  ****  *******     This is where we talk about the things
  *********  ***  *********    we're working on.
 **********  **  ***********
***********     *************  Most things start as messy ideas before
 **********  **  ***********   they get polished into finished features.
  *********  ***  *********
   ********  ****  *******     This is a place for messy ideas.
    *******  *****  *****
     *******************       For the completed product see kwoosh.com
      *****************

###############################################################################

How Kwoosh handles soft deletes

Normally, when a part of a discussion about your project is deleted, it’s gone forever. Depending on the particular discussion, it may not be a problem. Rather than delete data, Kwoosh allows you to remove data. The subtle difference in meanings between “delete” and “remove” makes all the difference and this difference heavily informed our implementation.

Some things we considered:

  1. What happens if a user clicks a link on an old email into Kwoosh and the item has been removed? If the item was deleted, there would be no data to display and we return 404 Not Found. The consequence is that the email has lost vital context and information. Knowing that data could just be gone forever could make people cautious about referencing data in Kwoosh. If you’re cautious about referencing it, then you’ll get it into the system to begin with.

  2. After an Item has been removed, what happens to it’s child items? So if you remove a task with 3 sub-tasks, do we also remove those sub tasks as well?

  3. If a user can view removed data, they will want to be able to restore it some of the time. How do we prevent data from appearing in the system when removed, and upon restore, appear in exact state that it was before being removed originally. i.e. removed sub-tasks are still removed and previously uncompleted tasks appear as open in the system again.

The way we handled this was splitting visibility into two different flags: status and visibility. Status denotes the status of the item as either ACTIVE, or INACTIVE. While visibility controls visibility as either VISIBLE, HIDDEN, or MASKED.

To keep us from accidently showing removed or hidden data we set our default query to filter only ACTIVE items. To queryallitems, we must explicitly query all_objects. It looks something like this:

In our example above of a task with 3-sub tasks all items would default to ACTIVE, VISIBILE.

When we remove the parent task, it becomes INACTIVE, HIDDEN. Uncompleted children are then updated to be ACTIVE, HIDDEN while completed tasks are not modified and remain as ACTIVE, MASKED.

A couple of methods allows us to remove and restore entire trees of data in a very simple and speedy way.

—jvd