next »

[shamblett]

This is an auto-generated support/comment thread for Auditor.

Use this forum to post any comments about this addition or any questions you have regarding its use.

Brief Description:
Auditor allows database level historying of the main MODx database for auditing/versioning purposes.

[bwente]

Very exciting stuff!

Also no data comparison/versioning/recovery/rollback facilities are provided yet. These will have to be done by other external tools. I intend to implement some of this by adding future 'plugins' to the Auditor module for say document content management, snippets etc.

I hope everyone gets onboard and create some plugins.

[jjhamblett]

Let the development begin!

[shamblett]

OK version 1.1 of Auditor is now in preparation, this is needed to allow data recovery fronm the history databse as marked by the Auditor analysis tool, hopefully this will only take a few days, stay tuned.

[shamblett]

Auditor 1.1 is now available form the resources section.

[shamblett]

I've just downloaded and installed MODx 0.9.6.2 to check its OK with Auditor and it seems to be.

As far as I can see a column named 'empty_trash' has been added to the 'user_roles' table but Auditor will just ignore this, ie it will not be copied to the history database. The rest of the database seems unchanged.

I'll put a fix in to allow Auditor to work with both 0.9.6.1 and 0.9.6.2 in version 1.2, along with a few minor bug fixes.

[Thanatermesis]

Just tried in modx 0.9.6.2 and not looks like to work (new install)

More info:  http://thana.no-ip.org/shots/deleteme-auditor.jpg

[shamblett]

Hi Thanatermesis, yes I got your mail OK, now onto the prob, it appears that either your

../assets/modules/auditor/php

directory doesn't exist or is not readable by your webserver user.

Auditor sets its path relative to the MODx base path setting i.e it uses $modx->config['base_path'], from your screenshot this would appear to be OK.

Please check that the auditor directory and its sub-directories exist and are readable.

[Thanatermesis]

Ok i found the bug/problem

The reason is that the unziped directory (so i don't have renamed it), its called auditor_1.1 and i have found a line in these errors that says that search the directory auditor and no auditor_1.1, so i have moved the dirname to just auditor and it has worked   (please use the "auditor" name in the zip file that works for everybody)

Btw i have read your before lines about a small problem in this version with 0.9.6.2 about "empty_trash" that you need to made a fix in Auditor_1.2, when you plan to upload this version ? (so maybe i will wait to continue with the install of Auditor)

Thanks!


Thanatermesis

[shamblett]

Yes, sorry about that, bit of a bug,  I'll look at this for the Auditor 1.2 release.

An extra column was added in 0.9.6.2 that Auditor currently wont history as its really based on 0.9.6.1, as far as I can see its to do with an empty trash check
or some such, its very minor, most people are only concerned with recovering the content of snippets, documents, chunks etc. which this wont affect at all.

This will be added in Auditor 1.2 but this release is about 2 weeks away at the moment.

If you really need to get up and running now I'd install Auditor and carry on, this shouldn't affect you at all.

[Thanatermesis]

I have tried it FASTLY in a tests website (affortunately) and because I have used the same database name, it was cleared!, everything removed

Mmmh, maybe could be better to add a kind of security system in order to NOT continue if the user as inserted the same database name at the modx uses ?


Thanatermesis

[shamblett]

What should happen is that say your main MODx database is called 'modx', the Auditor installation screen will assume that your history database name is called 'modx_history'. This database must exist of course. You can change this if you wish BUT if you change it to be the name of your main MODx database ie 'modx' say it will trash this database. This is a good catch  , something else for version 1.2, I'll check for this and stop it.

As for permissions, your history database needs the same ones as your main MODx database for your user but it needs more permissions to install the triggers, this varies depending on your MYSQL version, see the document database_setup.txt in your Auditor directory for more detail here

The easiest thing to do here is just create a databse, the same name as your main MODx databse with '_history' appended.

[Thanatermesis]

I have a more big problem now... looks like I can't install it because i don't have these permissions, I have no problem creating and modifying permissions in the DB's myself but the website is on a virtual-hosting (no root)

It is not possible to use this module with just using a different database without the need of these privileges ? :/


Thanatermesis

[Thanatermesis]

I don't understand, I have installed it on my local machine and it records events and everything but looks like it doesn't view any "mark", i have modified and removed documents, also removed a chunk, and there's no "marks" in Auditor :/


Thanatermesis

[shamblett]

You need the correct MYSQL privileges to install the triggers on your main MODx database, there's not much you can do here if you don't have these unfortunately.

Marks are not set by Auditor, they are only read and processed by it. To set marks you have to install the modx-audit-analysis tooslet. This installs into your history database and allows you to view historied content and select it, i.e mark it for  recovery. When these marks have been set Auditor will recover the data from the history database.

You could of course do this by using phpmyadmin or some such db admin tool to view the content of the history tables and just copy and paste the stuff you need.

[Thanatermesis]

Since it is strictly required these privileges, I think that i can't install this module on my modx website

Maybe I look in a future time to made a similar plugin (not module) to use simply the plugin events and record the pages saved and other things in other database (normal database, without these super-privileges needed)

Thanatermesis

[shamblett]

Sorry you can' use this in your set up but your efforts are not in vain, you've found 2 bugs here that I can roll into the next release, thanks.

[Thanatermesis]

No problem

Im developer too so i know how importants are the reports


Thanatermesis

[insert_nick]

With Auditor 1.2 every action is recorded in a "history" database.
This makes me think a multiple undo/redo feature for MODx manager could be added into the Auditor module.

Like this (just an example):

1) I delete a chunk.
2) Oops, damn I want that chunk back, I realize now it was a good one.
3) I enter the Auditor module page.
4) I click once the undo button, and I read on screen "CREATED chunk ......... (etc.)"

..or even like this (just another example):

1) I delete a chunk.
2) I create a document.
3) Oops, damn I want that chunk back, I realize now it was a good one.
4) I note down somewhere the relevant fields of my just created document, because I'm going to lose it.
5) I enter the Auditor module page.
6) I click once the undo button, and I read on screen "DELETED document ......... (etc.)"
7) I click the undo button once again, and I read on screen, after the previous sentence, "CREATED chunk ......... (etc.)"
8) I create the document again and fill it with the stuff I noted down before.

I'm happy with that chunk that otherwise I would have lost forever.

Similar thing, if I want to "redo" actions, you know how it works in other pieces of software.

[shamblett]

Interesting, I didn't want to get into this in the auditor module as selecting the correct version of something to restore is not as simple as you may think, but having said that If we constrain it to being 'the last update' this makes things much simpler, a simple drop down list of entity types such as document, chunk, snippet etc. with an undo button would be simple enough. You could also make this just undo deletions only e.g. things you've deleted by mistake as you've said above and not normal creations/updates.

I'll have a think about this for Auditor 1.3