MinimumLogEventLevel is ignored about serilog-sinks-slack

[alexvazquez]

Is this going be fixed?

[WebSerGe]

I found the issue, Serilog.Sinks.Slack/Models/SlackSinkOptions.cs contains MinimumLogEventLevel and no more options related to log level. However, if RestrictedToMinimumLevel (which is absent in SlackSinkOption) is added to configuration file appsettings.json then filtering of events works.
RestrictedToMinimumLevel exists in Serilog.Sinks.Slack/SlackLoggerConfigurationExtensions.cs and MinimumLogEventLevel is absent there.

[TrapperHell]

Apologies for the delay. I meant to get back to you sooner, but I've been quite busy. Unfortunately there's a couple of issues here, so I can't quite decide what would be the best course of action.

Let's start off with the simple bit: The MinimumLogEventLevel property may be a somewhat misleading since it's available in the options file, but not within the configuration extensions.

The fix for it is somewhat unclear though. It is simple enough to expose the property in the configuration extensions, and the issue would be solved, however we would end up with two ways to configure the logging level. As you've quite rightly mentioned, there also exists the RestrictedToMinimumLevel property, which achieves a somewhat similar function.

There is however a couple of nuances. First off, the latter argument is handled by Serilog's sink configuration (LoggerSinkConfiguration.Sink()) and thus requires no real backing-property in the Options model, or custom-logic to make it work. However at runtime this property can only be raised (ie. the minimum level cannot be lowered). Going off at a tangent, it does seem like the method I've indicated here is due for removal from Serilog at some time (as the message reads: Provided for binary compatibility for earlier versions, should be removed in 3.0. [...]).

On the other hand, the MinimumLogEventLevel property allows for both raising and lowering at runtime, however this is manually controlled by the sink logic (which should already be in place).

My main concern here is that adding another argument that controls logging level in the configuration may make matters all the more confusing, and downright replacing the other argument is probably a bad idea (even though not breaking).

At this point I'm not sure whether to just add this argument as well in the configuration extensions, or if there's a better way of achieving all this. I'll need to think about it some more. In the mean time, feedback is welcome.

[TrapperHell]

Hi @alexvazquez ,

The issue is still open, and intended to be fixed at some point, however I don't think it would be any time soon (at least not from my end). However if you'd like to adjust it to match your needs, I don't think it should be too intensive. You could also issue a pull-request if you do go on about fixing it, and I'll see if I can include it in the base.

I'm pretty time-constrained at the moment, and there are some other matters with the project that I would like to address before going over this.