Right now, it's only tracking a few events since that's all that the code's been designed to work with. Theoretically, we could put anything and everything in there if we wanted to. Once we have it implemented, we should also log when files are uploaded and deleted, for example.

The events are currently decorated with an icon stored in /www/images/tracker (e.g. we have a pacman like for comments)

• @todo maybe change those to less offensive css styles, like those used here on GitHub

Welcome back to issue 77 :-D

As we've progressed on the data processing, one thing we need to do is add in other activity logging. Joomlacode logs changes to the title, category, and status (maybe more, I only took a look in a couple of tracker items). The discussion at this point should focus on what we want to log then act accordingly.

The method in IssuesTable::processChanges() should record pretty much every change.

So in looking at the code, there's a huge lack of consistency in how we're interfacing with the database. We have some places in which we're manually building INSERT/UPDATE queries, some places where we're calling AbstractDatabaseTable::store() directly, and some places where we're calling AbstractDatabaseTable::save() (that one being the correct behavior for when we're using a table object). That'll cause processChanges() to not get executed when we're using IssuesTable since the oldObject property won't ever get set.

Assuming I didn't break something along the way, I've cleaned up the hooks to always go through AbstractDatabaseTable::save() which should let us catch everything now.

Looking to be good to go with everything, consider this closed (for real this time, not like the two false calls just above this comment).