And you mean just logging it on hub to standard log, or some more elaborate notification (e-mail, etc.) ?

An email would be more invasive but potentially very useful.

The goal is simply to be able to identify who/what/when (and from there... why) is overriding an established policy. We could work from logs, but a notification pushed out to some list would help too... or even a messagebus event.

Note that I'm filing this on behalf of others, so please forgive me if some of my reasoning appears to be vague as to what the most ideal situation would look like. The whole goal, as it's been expressed to me, is to be able to discover somehow that policy was overruled.

Simplest variant is in #2019. We can extend also protonmsg plugin to send info about these events, but maybe this is sufficient?

Nothing in the current hub code sends emails directly, and I'm not sure this feature is where we should break that habit. I do think we need a better solution for getting this sort of feedback to admins, but I'm not sure what that is.

For the moment, I think that printing details to the hub log is probably sufficient.

We can extend also protonmsg plugin to send info about these events, but maybe this is sufficient?

The plugin is mostly just passing through the callback data, so this would be a matter of adding/adjusting callbacks.

I see two basic paths.

1. add data about forced changes to the existing callbacks
2. add new callbacks (and make sure protonmsg handles them)

logs would work, absolutely. That meets the requirement of being able to find out that a policy denial was overruled.

is that ok to have a flexible table like actions or policy_actions to log all the policy assert actions and --force actions?

I don't think, we need additional table, we can use those versioned ones (tag_packages, etc. in this case and add there e.g. field 'forced'. Then you can see it in list-history. We can build around that query like "show me every use of force in last month" But, that's probably another RFE.

But, that's probably another RFE

Yeah, I don't want to take this particular issue too far when simply adding some additional logging will do.

Commit 336c3ba fixes this issue

Commit ccb7a15 fixes this issue

This isn't actually what we were looking for. These changes simply are a catch for when the force option is used at all. What the RFE is for is logging when force is used AND it overrules a policy. In other words, the policy must have been such that the action would have been blocked.

So for example, one would need to run the policy check always, capture the result. And then only if it would abort the activity check whether an admin had used the force option. And if they have, disregard the policy result and log that the policy violation was overruled.

And frankly to make it easier to work with, I'd recommend wrapping that all in a new function similar to how assert_policy works now -- just maybe have it take a list of potential permissions plus a boolean for force. That way the branching logic and logging doesn't have to be duplicated everywhere. That's up to you though.

Makes sense: PR #2098

Commit 7e169c8 fixes this issue

Commit f55c9e4 fixes this issue

a trivial fix PR #2147

Commit be61a98 fixes this issue

Commit 293cc87 fixes this issue