Support/Comments for Auditor

I already intended to consider only the last update, just like normal multiple undos/redos behave in applications (edit: re-reading your reply I realize now you already had understood this - or maybe not - I’m unsure).

Your idea of a drop down and only undo delete actions is good, but I’d prefer a normal multiple undo/redo feature as explained, it’s more linear and straightforward for user, and we’re just addicted enough to this way with other desktop and web apps that it would be somehow confusing for some users to use smoothly a never-seen ever feature.

I’d also like it to do not only deletions, but also creations and updates, because sometimes updates can mess up things just like deletions. Creations could be omitted, but I prefer not just because it’s simpler, and linear, and avoids to confuse the user while going backward and forward into an history line.

So, just like that:

<-[UNDO] [REDO]->

action 1
action 2
action 3
action 4
action 5 <---
action 6
action 7
...

...whatever "action x" is (deletion, creation, update, of document, of chunck, of snippet...)

This way it would work even if future version of MODx will introduce some other thing like tv’s, chunks, etc. (the Auditor would need adaptations, but not so much its undo/redo feature.)

Thanks for taking my proposal into consideration for future versions of Auditor (of course even if you want to go with your way: you’re the boss on it

Quote from: shamblett at Oct 11, 2008, 07:53 AM

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,

I’m a little confused about this sentence. Do you mean it’s not easy to do the "multiple" thing, so we have to be happy with only a "one step" undo/redo?
I hoped it was something like going in a line where actions can be determined by a (complex?) query on the history database, sorting descending by timestamp... or something similar.

You know your thing, I’m just thinking loudly without knowing the details of your module.

Sorry, yes, I didn’t mean that the SQL was particularly difficult, its more to do with the presentation of the results in the Auditor module itself. The companion tool modx-auditor-analysis uses datagrid TV’s and RTE windows to allow people to select and view the content of entities before they select them for recovery. This is a bit of a heavy hitter though for most people who like you say may just want a simple undo/redo facility.

A problem we will have here is reflection(we have this anyway at the mo) whereby if say a document is undone from history it will either be created again or updated in the main MODx database. This action causes the update/insert triggers to fire and so this row will be ’reflected’ back into the history database, undoing a second time will select this row, as its now at the top of the undo list in time, not the one the user probably wanted, i.e the one before the one he’s just done, if you follow my logic here. That’s why at the mo the user really needs to see the content he wants to recover.

We could drop the relevant trigger while we undo, thus stopping the reflection, but we may lose updates while the trigger is off(unlikely I know, but possible). We may be able to be smarter and cope with reflections, I’ll have a think.

This would work for deletions as it stands, as deletions are marked a such by the delete triggers, reflected updates wouldn’t be seen by this action as they are not marked as deletions

I think this has been suggested before, by another poster who wanted an extra tab or button on content panes themselves, i.e. on a document somewhere say, so you could do this from the entity itself without going into the auditor module but I think this would need core changes(may be wrong here). It seems to be something people would want so I’ll have a look.

Quote from: shamblett at Oct 11, 2008, 11:45 AM

A problem we will have here is reflection

woah, true! I didn’t think to that at all...
Seems quite a difficult game to solve.

Quote from: shamblett at Oct 11, 2008, 11:45 AM

I think this has been suggested before, by another poster who wanted an extra tab or button on content panes themselves, i.e. on a document somewhere say, so you could do this from the entity itself without going into the auditor module but I think this would need core changes(may be wrong here).

Moreover, I feel this is not a better solution than mine, because e.g. this way it wouldn’t be possible to restore a deleted and trashed item, etc. I mean, a useful undo/redo system should be application-wide, not just item wide.

I hope someone here can suggest a way to solve the reflection issue puzzle, possibly better than your trigger dropping dirty trick

Hi, congrats on the great plugin! I’ve been playing with it on my local setup and it works great. However, I can’t use your plugin on my live site because my hosting provider requires a different user name per database created. So, to make this work your plugin would have to allow me one of the following:

A. Specify a different server path/user name/password for the audit database
B. Use the same MODx database to store the audit database

Obviously I would prefer a fix based on A, but I can manage with option B. Is there something I can do with the code to do this?

Thanks and keep up the good work!

Hi, thanks for your feedback. I don’t think B is a good idea, having a separate database gives you lots of advantages in backup/recovery, data separation, performance etc. but A is doable.

Auditor just picks up the database settings from the config.inc.php and uses them. It should be possible to override the user name in the module code itself and any other parameters for that matter, i.e. at the top of the module code set $database_user to what you want, the code doesn’t use the MODx DB API,it opens its own connection with its own parameters so this should work but I need to check this.

I’m going to release Auditor 1.3 just after 0.9.6.3 is released so we can pick up its sql templates and a few other things, I’ll have a look at this as well, there may be some code to change here to support this. Please feel free to experiment with this if you wish and post your findings.

Well when you release 1.3 I will be doing some testing on it and hopefully you can get to modify the code to allow the possibility I suggested.

Thanks for your reply!

The table creation statements seem a bit lengthy. MySQL supports a table creation syntax of the form:

[tt]CREATE TABLE newtable LIKE oldtable; -- will copy the definition of oldtable
[/tt]
If it is required to add extra columns or remove existing ones you could provide ALTER TABLE statements. Might make the code a bit simpler to maintain. Of course preserving Auditor tables across MODx upgrades where columns might have been added or removed would be a nightmare but I’m guessing that is already the case.

IMHO this feature should have been an integral feature of MODx since day 1, I am currently working with a customer who is paying for ExpressionEngine rather than using MODx simply because EE has this feature built in and integrated.

Yes, the initial implementation was intended to be safe and functional, if not optimized and a little clumsy, but it was always intended to be at the DB level, so as not to impact MODx or any other DB user by impacting their code. I realize that in some corporate environments this is a must as you say, hopefully in revo at some stage this will be a de-facto addition

Hi all, Evo 1.0.0 release slipped by me a little here. I’ll be releasing Auditor 1.4 for 1.0.0 in the next few days for those of you needing this.

I’ve also been asked about a possible port to revo. I can do this if enough people want it. Revo is going to get its own auditing/content versioning system in a later release so this will probably only be an interim solution for migration purposes but no matter it can still be done if needed.