This gives vaious levels of reporting, and I want it to send logs only for warning events or worse eg fatal.
I have seen how to do this from the command line, but using the gui do I have to add separate filters for each event?
I believe you can use a semicolon comma separated list of the items you want to include. (Please correct me if I’m wrong as I haven’t actually needed to do that yet.)
New log system with filters may be worth a look. There are more options in latest canary than in 2.0.3.3 beta. I’m somewhat confused by the question. For controlling sending, use --send-http-level, to set outcomes which send logs. The --send-http-log-level is seemingly like similar controls on other logging, and sets the threshold to control line-by-line what goes into the log, which the --send-http-level setting may or may not actually send.
As for command line versus GUI, I think these are the same. In GUI, you set advanced options, and read help:
send-http-level You can specify one of "Success", "Warning", "Error", "Fatal". You can supply multiple options with a comma separator, e.g. "Success,Warning". The special value "All" is a shorthand for "Success,Warning,Error,Fatal" and will cause all backup operations to send a message. Default value: "all"
send-http-log-level Use this option to set the log level for messages to include in the report Default value: "Warning"
I read this too, but the GUI only lets me select one value from it’s drop-down, and hitting comma does nothing
Logically, anyone who wants “warning” reports would want to be advised of any worse events, but exporting to command line shows only --send-http-level=Warning implying I need to enter separate --send conditions for each.
Recommendation for change ie >= chosen event.
Unless I am doing something wrong which I am quite happy to believe.
Thanks for clarifying (and the “Send-http-log-level” topic is now misleading – I wonder if it can be edited?).
I set up a web server and tested this some on 2.0.3.11 canary. There’s definitely a disconnect between the GUI handling and the help text for --send-http-level and --send-xmpp-level. A comma-separated list can’t be entered during a job edit in the GUI, and editing it into a job exported to run on the command line also fails:
The option --send-http-level does not support the value "Warning,Error", supported values are: Unknown, Success, Warning, Error, Fatal, All
What’s accepted on the command line (but probably doesn’t do what one intended) is a series of individual settings. What seems to happen is the rightmost one wins. Source code does look like it would split a string the way --send-mail-level does, but the GUI presentation and the option checking make its entry impossible.
While the idea of levels has some appeal to me (not that I have much to do with the decision…), there are a couple of values that might be hard to put in an ordered sequence, e.g. is “Unknown” a category unto itself, and where does “All” fit? If one views this as kind of a level setting only beyond which the log is sent, “All” is way on the left, looking at the sequence in the error message above. If it weren’t for “Unknown” though, “All” would seem equal to “Success or above”. Whether or not this is the best direction may also depend on any future directions that logging and error classification plan to go if there’s any general improvement intended.
Alternative options include making the reporting settings work like --send-mail-level, or possibly even permit GUI-friendly multi-select like --allowed-ssl-versions, where the GUI turns that to a nice comma-separated list, which one can see if this operation is done in the job’s Commandline menu option (just toggle “Edit as text”).
If, say, success=1,unknown=2…all=0 it would presumably be fairly easy to have a >= test. I’m not a coder though.
I think there are design questions as well as code change. For example, how compatible should behavior be with prior behavior? Changing canary should be easiest, however some of this has been in beta a long time.
There’s also a question of how similar the various --send-*-level should be. One possible clue is that canary went to shared code for --send-mail-level, --send-http-level, and --send-xmpp-level on the sending decision.
Unfortunately the GUI and option validation appear out of alignment with the plan. Comparing the code setup for –send-mail-level, –send-http-level, and –send-xmpp-level, I see that only --send-mail-level claims to take a String, while the other two take an Enumeration, and then go to the common processing which takes a String. There are other differences , but I wonder how much of this could be solved by changing the latter two lines?
Regardless, thanks for the ideas, and I’m not sure what happens next. While one might view this as a feature request (which has a forum category and perhaps you can change it while also trying to fix the topic title), it’s also (in my view) a bug due to the disconnect between documented behavior and the way this actually works.
I think I’ll see if @JonMikelV has a thought on how to categorize this in the forum, or get it somewhere code changes can happen. With both the forum and GitHub issues, flow back and forth is awkward at the moment, especially when turning forum Support work into code fixes. Beyond that, bug tracking seems less than ideal. Things were better connected when key developers did more support, but we need them to do development.
I’ve flagged this as a ux bug for now since it’s unclear whether the docs it the interface are the intended functionality. I know @kenkendk redid logging “recently” so this my be incomplete or slipped through the cracks.
Personally, I think the enumeration (single choice) makes sense and should be combined with a --send-http-log-level-filter type parameter to allow specific message filtering (like exclude logging db calls).
Not that I haven’t worked with http logging at all so might be way off base with actual useful ideas. 
The problem here is that the --send-mail-level and friends actually take an enumeration. But the validation code and GUI expects an enumeration to be “on of them”, but this particular enum is actually a flag, so multiple can be entered.
I think a short term fix would be to change the option type to String such that the user can enter the values, and it matches the help text. This will not break anything for existing users, as it just means they can do more.
It was supposed to work like this I think. But looking at the code, it no longer works that way.
It is certainly easier for the user.
I am not sure we gain anything from allowing multiple options, so maybe we should just change it?
Thanks for that reply. If you just change it to single-choice, it’d cause somewhat less trouble among the existing backups if it’s done now, because it’ll mainly impact --send-mail-level users. Doing something like converting to the lowest issue level they chose would get what they had, and then some. Some other findings in case it helps:
The change for --send-mail-level from Enumeration to String might be here. The multiple select does remind me of Flags which might be more GUI-friendly (or maybe not because it’s so rare), while still allowing string splitting.
I tested Flags with GUI Commandline “Edit as text” to try –allowed-ssl-versions=Tls13, and was properly errored, meaning validation is possible. The default value also seems to be prepopulated for the user to click as desired.