Modify Client Delete Function in Anuko Time Tracker

Project Description

We are looking for a PHP programmer who can customize a client delete function in Anuko Time Tracker so that it deletes its associated time, expense, and custom field log entries. This is a remote job.

This PHP app is open source, you can download it from https://www.anuko.com

At the moment, when a client is deleted, the time, expense, and custom field log entries stay in the database. We need an option to delete such entries fom the database.

So, on the client_delete.php we want an additional dropdown field, similar like how it is done with invoice delete, allowing us to select whether we want to delete the entries or not.

Time Tracker - invoice delete options
Time Tracker - invoice delete options

The do not delete option should be selected by default. When user selects delete and clicks the Delete button, we want the entries to be removed (do not show up on reports anymore, as well as everywhere else).

The reason for this project is that we are working with many small clients and the interface is becoming a bit complicated with many entries as work progresses. We meed a way to clean up no longer needed entries.

Completion Notes

While an option to delete the entries looks simple to do, if we do it like invoice delete, then the entries will be deleted permanently. This is apparently a problem, as if the operation is done by mistake, and we anticipate such mistakes from users, there will be no way to recover entries.

So, a proper way of doing this, and actually redoing the invoice delete feature just as well, is not to delete the entries entirely from the database, but mark them as deleted with a special status flag. Parts of Time Tracker application already behave like this, for example: users. When you delete a user, the status field in tt_users table is set to NULL, but the user stays in the database. This way we have a method to do a manual recovery of a user (by finding and resetting its status flag in the database).

In other words, we are looking for an introduction of the status field into some database tables, and modifying Time Tracker code to deal with it.

Project Plan

We'd like to go with incremental small steps when doing this modification, maintaining overall functionality of the application between each step and having its upgradeable. Our project plan, therefore, may look like the following:

  1. Add the status field to tt_log, tt_custom_field_log, and tt_expense_items tables.
  2. Add code to support the status field in tt_expense_items.
  3. Same with tt_custom_field_log.
  4. Same with tt_log. By this point, deleting any relevant entry rather marks the entry as deleted, but it stays in the database.
  5. Add a dropdown control on client_delete.php and write code to mark associated items as deleted.

Adding Status Field

First, we modify mysql.sql ne adding the field to tt_log, tt_custom_field_log, and tt_expense_items tables:

`status` tinyint(4) default '1'

Second, we need to add this change to dbinstall.php:

setChange("ALTER TABLE tt_log ADD COLUMN status tinyint(4) default '1'");
setChange("ALTER TABLE tt_custom_field_log ADD COLUMN status tinyint(4) default '1'");
setChange("ALTER TABLE tt_expense_items ADD COLUMN status tinyint(4) default '1'");

After fatabase structure update, our tables have the needed status field, which is set to 1 by default. Time Tracker continues to function as before.

Handling Status in tt_expense_items Table

In this part of the project, we modify the relevant parts of Time Tracker code that deal with tt_expense_items table. For example, instead of deleting an entry we set the status to NULL, when retrieving we check for status = 1, when migrating data we need to export / import the status field value together with other values, etc. About 10 files are affected.

After completing this step, we still have a functional application. However, deleted expense items have their status set to NULL in the database and they are migrated during data export / import.

tt_custom_field_log Table

We can now go with similar modifications for tt_custom_field_log table. Changes here are similar to the step above.

tt_log Table

Now let's proceed with modifications to handling tt_log table entries. Notice that we can further divide the scope for this change by first supporting export / import function and then everything else. To do export / import, we have to modify 3 files: ttExportHelper.class.php, ttImportHelper.class.php and ttTimeHelper.class.php. To avoid setting status field in time.php and time_edit.php files, we will automatically determine if the status array key exists in ttTimeHelper::insert function using array_key_exists().

We do modifications in other files that deal with tt_log table. When this work is done, we have a fully functional Time Tracker. Deleted tt_log, expense_items, and tt_custom_field_log entries stay in the database with status = NULL. Also, export-import procedure works.

Modifying client_delete.php

In this phase of the project, we modify both client_delet.php and client_delete.tpl files to have an additional dropdown control, which defines whether we mark entries as deleted or not.

We also have to modify the ttClientHelper::delete() function to support this.

Time Tracker - client delete options
Time Tracker - client delete options


Finally, after testing everything, we see that the new feature works properly. This completes our Time Tracker modification.

You can leave a comment on this project, or post a new project for consideration.