Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Event Types on Activities Table #77

Closed
davidhurley opened this issue Jan 24, 2013 · 7 comments
Closed

Event Types on Activities Table #77

davidhurley opened this issue Jan 24, 2013 · 7 comments

Comments

@davidhurley
Copy link
Contributor

Currently the event types is a VARCHAR field. It appears we have comment / open / close as data that is tracked by this activities table. Will there be other event types that are available. When looking at reporting etc, it's nice to know all possible activities we're tracking.

@mbabker
Copy link
Contributor

mbabker commented Feb 1, 2013

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.

@elkuku
Copy link
Contributor

elkuku commented Jun 29, 2013

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

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

@mbabker
Copy link
Contributor

mbabker commented Aug 19, 2013

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.

@elkuku
Copy link
Contributor

elkuku commented Aug 19, 2013

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

@mbabker
Copy link
Contributor

mbabker commented Aug 21, 2013

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.

@mbabker
Copy link
Contributor

mbabker commented Aug 30, 2013

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.

@mbabker mbabker closed this as completed Aug 30, 2013
@mbabker mbabker reopened this Aug 30, 2013
@mbabker mbabker closed this as completed Aug 30, 2013
@mbabker mbabker reopened this Aug 30, 2013
@mbabker
Copy link
Contributor

mbabker commented Aug 30, 2013

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).

@mbabker mbabker closed this as completed Aug 30, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants