CMS Made Simple Core


[#11194] CMSMS Admin log hook

Created By: Ruud van der Velden (ruudvdvelden)
Date Submitted: 2016-10-24 12:43

Assigned To:
Resolution: Fixed
State: Open
CMSMS Admin log hook
Detailed Description:
A feature request regarding the possibilty for one or more modules to hook into
the built-in Admin log.

An example use case could be an administrator that owns multiple CMSMS websites
and has a server running a syslog receiver. A custom CMSMS module (syslog
originator) would be able to 'catch' important events and send those to the
syslog receiver. This allows professional users maintaining multiple CMSMS
install to centralize monitoring and alerting.

I think it would be nice to have the possibility to allow multiple modules use
the hook simultaneously/serial.

Perhaps the CMSMS Admin Log 'page' itself - as it currently exists - should then
be a module too (which can be disabled in favor of another module). Just
thinking out loud.

A log message should have some properties which can be used to
filter/differentiate the messages:

1. originator (e.g. Core, Module Name, Plugin Name, UDT name)
2. severity level (e.g.
3. [optional] event id (e.g. numeric id defined by the originator, for filtering
4. message (the message text). Multiple lines allowed?

Currently available:

5. ip address of 'client'
6. (admin) user name
7. item ID (e.g. content object id or template id)
8. Item name
9. Action (the message as listed in [4])
10. time stamp

Debug log messages in this same log/hook too?

Obviously CMSMS is providing the hook. Other modules are responsible for using
the hook and doing the actual logging to other systems like syslog, a time
series database or other logging/alerting system(s)


Date: 2018-07-15 10:09
Posted By: Robert Campbell (calguy1000)

In CMSMS 2.3 the auditing has been revamped.

There are now 4 functions:
audit() // for compatibily
cms_notice( $text, $subject );
cms_warning( $text, $subject );
cms_error( $text, $subject );

These 4 functions in the global namespace now are just wrappers around
\CMSMS\AuditManager::notice and \CMSMS\AuditManager::warning() etc.

The CMSMS AuditManager class is responsible for dispatching the message to an
'auditor' .
The auditor is a class that can do various things with the various functions. 
i.e: output using php's error_log() or store the data in the database.   It has
a set_auditor() method that allows for setting a single auditor at runtime.

A brand new core module,  AdminLog replaces the /adminlog.php functionality.  
When it is initialized, It calls AuditManager::set_auditor() method so that it
is the preferred auditor() class.

The AdminLog module has more functionality than the old /adminlog.php stuff.   
It stores messages in the database, AND it also outputs notices, warnings, and
errors to the php error log.

If somebody wanted to use syslog or some other mechanism all they would have to
do is:
a:  Write a small module that created a new auditor object, and registered
itself as the auditor.
b:  Disable the AdmlnLog module.


Updated: 2018-07-15 10:09
resolution_id: => 7