There is a whole class of 'config edits' which are strictly speaking not config edits because they are not in mdl_config or mdl_config_plugins, but most admin's would think of them in the same way. Essentially anything in an admin externalpage.

There is also a large class of these 'other config edits' which currently don't emit a moodle log entry either, such as disabling or editing a scheduled task (see MDL-66287) so there is currently missing audit trail. The more you look the more you realize how much isn't logged like enabling / disabling plugins, changing the order of auth plugins, crud'ing OAuth services. I'm kinda scared to keep looking.

The 'config changes' report is good, but I think conceptually should show all of these changes: 

/report/configlog/index.php

Also I think it could be improved a lot, eg obvious things like filters, but it would be great down the track to layer on the ability to revert a config change - which means it needs to remain highly structured so it knows how to reverse a changed. Right now that is trivial but I'm thinking of reverting the delete of something complex like an OAuth2 service with lots of parts to it.

I'm not really sure the best approach though, either we:

a) change the schema of mdl_config_log / add_to_config_log() so that it can accept more general classes of config changes

Pros:

• ?

Cons:

• lots of code touch points to push the data into it

b) the config changes report needs to pull stuff out of the moodle log.

Pros:

• config changing code just emits an event

Cons:

• The moodle log doesn't have the structure required, all the
• will be extremely slow and /or impossible to query if the logs are truncated or an external log store is used etc

c) or maybe something a bit larger building on (b):

Calling add_to_config_log() also emits a moodle log entry. Weirdly these log records reference a 'create' on the mdl_config_log table which seems a bit off, wouldn't it be more accurate to report an 'updated' (or create/delete) on the real mdl_config_plugins table instead? We would certainly not 'undo' something on the mdl_config_log table.

It seems to me that in hind site this is the wrong way around, it would be better if:

a) there was a base 'config change' event class which things could extend and the config changing code just emits the event. This base class would define the semantics of how to show before and after values and how to restore the state in its log event

b) The config changes report can then have a log observer and filter out just the config events out and stash them as needed for faster and persistent reporting.

c) deprecate add_to_config_log() as it's redundant