Support/Comments for Auditor

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

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.

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

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

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.

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

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.

No problem

Im developer too so i know how importants are the reports


Thanatermesis

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.

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