Okay, Umlauts again 
The character encoding is relevant as follows:
Icinga Web (UTF-8) << MySQL (latin1) << Icinga (UTF-8)
Icinga writes its data correctly into the database. The database accepts it then as latin1, though byte-wise it’s still UTF-8. If interpreted as such, as it’s then done by Icinga Web.
I know, it sounds strange at first, but think of latin1 as a 1:1 representation of Icinga’s data (raw bytes). The real encoding doesn’t matter at all, it’s all up to the reader to interpret it correctly.
The IDO schema defines a hardcoded encoding/collation in various places since, well, forever. That’s latin1/latin1_general_cs. The default encoding/collation of the database shouldn’t matter, because the schema defines them explicitly.
The same is done by Icinga Web in its queries. That’s the reason why it is necessary to define latin1 as charset in the IDO’s resource. Only this way Icinga Web fetches the data in said 1:1 representation and can then interpret it as UTF-8.
Yes it’s weird. That’s usually the case with bad decisions made in the past and the necessity to be compatible with legacy installations. Recent products all make use of UTF-8 throughout the entire chain without such hacks/workarounds. (Director, Icinga DB, …)
–
So, that’s all for now regarding an explanation on how/why it works. I can only guess what the problem might be, but I’ll only repeat what works for me:
- MySQL 8 (Basic installation, the official docker image)
- IDO schema import, without any changes or adjusted defaults
-
latin1as charset in the IDO’s resource configuration in Icinga Web 2
The last step is obsolete with v2.9, as then latin1 is the charset used by default for the IDO resource. (You’ve already linked the PR)
If this doesn’t work for you, make out any differences which may affect the processing that I described above. I hope this helps.