BootTrait - If no active user is given, then run CLI as superuser

[totten]

Example:

• Initially, the cv api4 command tended to complain because the default/unauthenticated condition was to fail the permission check. cv api4 currently has a work-around to set checkPermissions=>FALSE, although this wouldn't apply if you used cv ev civicrm_api4(...);
• The ang:module:list has problems listing CiviMail modules b/c they have a funny perm check.

I think this may actually be better than the current workaround in api4, e.g.

• Using checkPermissions => FALSE means that it never checks permissions.
• Using this would mean cv api4 Contact.get would run without permission checks... but if you specified cv api4 Contact.get -U alice, then it would apply the permissions of the named user.

I haven't tested the impact on that api4 use-case. I initially wanted to improve the ang:module:list case, but something else in CiviMail still makes that funky.

This could be a change if someone has a custom-script that is intended to run as anonymous+unprivileged user (cv scr my-script.php), although I suspect that's the exception rather the rule.

Anyway, I'm just gonna file the PR and the let idea gel a bit more.

[stesi561]

Is this still relevant?

I like this concept!

[totten]

(@stesi561) Is this still relevant?

I like this concept!

Yeah, I think the same idea/critique still applies -- that it would be more systemically consistent to set a default super-user for CLI commands.

Another example of this came up with cv cron (where you want to run cron as a super-user -- rather than manually creating admin/user/role). The implementation in cv cron is newer, and it's a bit better than this PR, in that it sets the active-identity. (In the change-log, any changes by CLI superuser are attributed to the domain-contact.) But the scope there is only the one command.

Rather than merge this PR, it probably makes more sense to re-factor the stuff used for cv cron and promote it to work many/most commands. (And maybe introduce an option like --anon to allow explicitly-anonymous actions.) (In any case, this PR is conflicted...)

The other angle (which applies to #56 and also #145) is that a policy-change could be compatibility-break. So it would be nice to do coordinated increment (e.g. 0.3.69 => 0.4.0) with these two policy-changes.