The Macrotone Consulting Joomla Audit component also known as JAudit was developed from a feature within a version of the Issue Tracker component which was specifically tracking changes to Issue Tracker tables. This worked so well whilst being developed that it has been reworked separate component in its own right.

At initial release it runs upon Joomla 3.1 and 2.5 and supports MySQL databases, the most common database used by Joomla based system.

Change log

Translation Credits

Requested Features

Release Versions

Release 1.0.1

This will be a bugfix and minor enhancement release.

Release 1.0.0

The is the initial release of the component.

end faq

Frequently Asked Questions

JAudit overview.

The documentation in PDF format and also as web pages is available upon the site. [Please see links under 'Joomla Extensions' on the site.] This document only presents a brief overview of the functionality.

The component only possesses a back end administrative interface.  There is no requirement for any front end interaction currently defined.  The whole purpose of an auditing package is to record changes and make then available to an authorised and approved individual or role for review and for any appropriate action to be initiated if required.

As befits an auditing package, no editing of the change records is permitted even by Joomla administrators.  Be aware though that people with direct database access can still make changes to audit records, so protection of the underlying database access has to be ensured to prevent these types of changes from occurring.

The real work of the component is performed by the underlying database (MySQL), with the Joomla interface serving to initially create the required database procedural code, and to provide a viewing mechanism.

We trust this brief overview is sufficient to cover the main features of the component and you are requested to look at the full PDF documentation for more information.

If you find this component useful, you are requested to raise a review on the Joomla Extensions Directory, and possibly consider making a donation to assist in providing support and future enhancements.

MySQL™ is a trademark of Oracle Inc.
 

Translation Credits

We would like to thank all the people who have donated their time and effort in providing translations for our extensions, either individually or as part of a translation team, so that they may be used by the wider community. 


Requested features being considered for future releases.

 Requested Change Possible Version for implementation
Ability to edit generated triggers ?
Ability to integrate with an existing triggers. ?

Leave your comments

Post comment as a guest

0 Character restriction
Your text should be more than 25 characters
Your comments are subjected to administrator's moderation.
  • Guest - Dimosthenis

    Hi
    The captcha doesn't work in the registration form so I cannot register so I will post my comment here.
    I installed the JAudit which worked as expected. However it can't audit all the tables of the db. I can create triggers of all J! tables but not tables which are in the db but have been created by me.
    Another problem is that when I created a trigger for the Users table in J! 2.5 in order to track the changes using AFTER UPDATE trigger, it didn't tracked the changed by (user). It just put 0 in the changes history tables.
    I think both of these are problems which needs your attention. Your extension is very promising and it will be very useful for me when you will check the problems above.
    Thanks for your attention
    Dimosthenis

    Comment last edited on about 5 months ago by Super User
    Like 0 Short URL:
  • Thank you, I appreciate your comments.
    The problem with the captcha not always displaying is one I am investigating. A page refresh usually works, although what is causing it, is not clear.
    I do not think that being making it work upon non-Joomla tables should be a problem, I will look and see how difficult (or not) it would be to implement.
    I will also look into the 'changed_by' user displayed values. There are a number of caveats around capturing 'who' has made a change, especially since Joomla 'does all he work' as the connection user, and the details of the 'real' user are not necessarily available in the database, where the 'infromation capture' occurs. I tried in the documentation to go into some details but I need to revisit that area again to see if it can be improved.

    Comment last edited on about 10 months ago by Super User
    Like 0 Short URL:

Supporting Partners

One and One
 
PHP Storm
 
Back to Top

The Macrotone Consulting Web site would like to use cookies to store information on your computer, to improve our website. Cookies used for the essential operation of the site have already been set. To find out more about the cookies we use and how to delete them, see our Privacy Policy.

I accept cookies from this site.