blacklist does not over-ride default about audit-stash HOT 6 CLOSED

That is by design, though. The blacklist is only an extra filter. I would suggest using a whitelist instead.

Keep in mind that modified is the same as the audit log date, since both happen at the same time

from audit-stash.

Is there any way to have AuditStash always fire? I'm subscribing to AuditStash.beforeLog in order to look for changes in related fields that AuditStash does not report, but without the initial log event, my routine is never triggered. Or, is there a way to manually trigger AuditStash.beforeLog and have it return the expected $logs ?

from audit-stash.

If the related tables also have the behaviour enabled, saving these related fields should also appear in the logs. Is that not the case for you?

from audit-stash.

I believe enabling the AuditStash behavior on related fields would trigger logs, but I need to combine the logs into a single transaction, as opposed to having the related tables in a separate log. So I'm looking for a way to essentially trigger the behavior on any add/edit in order to do the checking of the related fields.

from audit-stash.

yes, you need to re-build the transaction, that's the design decision I made for this library. You can manually trigger the audit logging. There is an example at the end of the README in this repo

from audit-stash.

I assume you're referring to the Transactional Queries example at the end of the README. It's not clear to me why you would be creating a new entity ($bookmark = $this->Bookmarks->newEntity();) nor where $data1 is coming from in $bookmark1->save($data1, $trail->toSaveOptions());. In my case I would want to include an address associated with a User edit, but it's not clear to me how I would do that with a transactional query. Any help would be appreciated.

from audit-stash.