The warnings are not filtered when logging to the results, so you cannot suppress them, which is quite annoying for a situation like the one you describe.
I have a fix ready for the next canary that adds --suppress-warnings=MegaUnmaintained,OtherId,ThirdId
This will change the warnings to information messages so they do not show up as warnings on the backup run.
Actually a good point. I think the nomenclature of all of those listed possibilities shall be more unique. Not only for the developers, but also for the users - but if it is already the case, then sorry that I’m still that blond…
How about a functionality for the new UI (but it is welcome for the old one too):
Clicking on a warning opens a (context) menu/pop-up with at least this menu on it: Ignore this warning class for this job in the future
This would do whatever is necessary not to show (i.e. not even generate) this warning class for this backup job (and also not for warnings it was earlier called for).
Internally, the code logs a lot of information, that you can see in the various logs.
When a message is logged with the log level “warning” it is captured by the backup results that can later be reported. The same logic is for log messages with the level “error” where they will be captured as errors.