To be frank, this cannot be a component level option. Even with this option, it is incomplete; the component MVC would also have to become aware of this. Enabling/Disabling the action log plugins should fulfill this option/desire.

Also, the MVC is written in a way where it should always be able to log. In fact, the action log component serves as the audit log for com_privacy, even if you were to disable all of the related plugins. So there never can be an effective killswitch for the action logging system in the component otherwise we are forced to create yet another logging system internal to com_privacy that can't be disabled.

So, should i review this by removing enable/disable option, and then removing preset core extensions from loggeable extensions option ?
In order to have User Actions Log disabled by default (many sites won't need logs to be enabled, and it could impact performance and MySQL stability on some hosting...)

If you intend on a PR that disables logging by default, then the plugins should be set to disabled instead of enabled. Haven't looked at anything else on this PR, but for that point IMO it should not be a component level option.

Basically, the component is there to provide an API for reading and writing data. But the component should not prevent writing data in full.

If you intend on a PR that disables logging by default, then the plugins should be set to disabled instead of enabled. Haven't looked at anything else on this PR, but for that point IMO it should not be a component level option.

Well, i mean not having core extensions all selected by default, and the possibility to disable all (UX issue #22627 )

Lastly, one thing to make clear in case there's any misunderstanding. This system is not logging literally every transaction that happens on a site. It does log things that perform save and delete actions, many admin related actions (extension install/uninstall type things), and user login activity (so for some ecommerce or forum oriented sites with large user bases, that can create a busy log system), but for sites where there is only one or two admins and no frontend authentication element there really should be minimal activity from this system.

So I get the concern that this can be performance impacting for larger sites, but it really shouldn't be as big of a performance concern as some might have thought.

Well, i mean not having core extensions all selected by default, and the possibility to disable all (UX issue)

Yeah, those bits are valid. Like I said, I really only singled out the "disable logging" option you've added to the component, which as I pointed out I don't think belongs for reasons already given (imagine if there were a similar killswitch option in com_finder for the indexer).

Yeah, those bits are valid. Like I said, I really only singled out the "disable logging" option you've added to the component, which as I pointed out I don't think belongs for reasons already given (imagine if there were a similar killswitch option in com_finder for the indexer).

Ok for the enable logging option, will remove.

About pre-selected core extensions, do you mean none selected by default could be an option (means database removal of pre-settings), or the possibility to disable all (by removing only form default element) ?

About pre-selected core extensions, do you mean none selected by default could be an option (means database removal of pre-settings), or the possibility to disable all (by removing only form default element) ?

The change you made here that allows a deselect/select all action is fine. And just leaving it defaulted to logging from all core extensions works. Otherwise you leave users to try and figure out what extensions should be logged when you actually turn the system on and possibly trying to figure out why nothing is being logged in the first place until they hit this config screen.

(Not to say that isn't a problem as extensions add support, but we can at least alleviate a potential pain point with core)

Thanks again @mbabker for the time you take to answer! ?

Otherwise you leave users to try and figure out what extensions should be logged when you actually turn the system on

The showon attributes could be removed then (this was one questionmark i had while adding showon...)

and possibly trying to figure out why nothing is being logged in the first place until they hit this config screen

Well, this could have been managed as for com_redirect (an alert message) ;-)

But this is not anymore the question, as logs may be enabled by default...

I will redo this PR with only checkboxes field improvement to select All/None (in this case, i have to remove the default attribute for loggeable_extensions to allow an empty selection).

I close here, and will redo the PR only for select all/none checkboxes field.