Per discussions such as #562, this sets up auditing to be dispatched on the Queue.
By default, the listener will go onto the sync connection. So if no configuration is done, the package will work as it did before, auditing immediately in the current request.
Once you configure the audit.queue.connect to be something other than sync, the audits will then be dispatched to be processed asynchronously.
Customization of the queue it is put on, as well as the delay, is also possible.
It is set up similarly to the Auditing/Audited flow. An Event (DispatchingAudit) is fired where you can prevent the auditing dispatch from happening by having a listener return false.
And there is the ability to swap out the ProcessDispatchAudit Listener if the end user needs to.
Per discussions such as #562, this sets up auditing to be dispatched on the Queue.
By default, the listener will go onto the
sync
connection. So if no configuration is done, the package will work as it did before, auditing immediately in the current request.Once you configure the
audit.queue.connect
to be something other thansync
, the audits will then be dispatched to be processed asynchronously.Customization of the queue it is put on, as well as the delay, is also possible.
It is set up similarly to the
Auditing/Audited
flow. An Event (DispatchingAudit
) is fired where you can prevent the auditing dispatch from happening by having a listener returnfalse
. And there is the ability to swap out theProcessDispatchAudit
Listener if the end user needs to.