Fixed Cyrillic encoded attachments issue

[akstis-typer]

Checklist before requesting a review

• I have read the CONTRIBUTING document.
• I have performed a self-review of my code.

Description

• It fixes Issue with cyrillic encoded attachments from mailbox #22997
• Here is a brief description of what this PR does:
  Changed MailCollector.php getDecodedContent method so that it checks for Windows-1251 encoding. It's easy to add new encodings to check if needed. Just add your encoding in $encodingsToCheck array

[trasher]

Seems correct after a first quick review.

A test case must be added. You can take a look at the PR which introduces initially the encoding check: #21575

[akstis-typer]

I guess mb_check_encoding() returning false for ISO-8859-1 and the Windows-1251 returning true - so it gets decoded. I'll think how to solve this issue

[trasher]

OK, thanks. I put this one to draft for now; feel free to switch back as ready when you're done :)

[akstis-typer]

I have hard time launching tests locally. I git cloned repo, install all dependencies I need (ran composer install, bin/console dependencies install) and tried to launch ./tests/run_tests.sh --build imap and when it builds, I got error from composer

file_put_contents(/var/www/glpi/vendor/composer/installed.php): Failed to open stream: Permission denied

I think that inside docker container the command runs with insufficient privileges however I tried to run script with sudo privileges and local user privileges - all results are the same. Can someone help me on that one? :)

[trasher]

I do not know/use docker at all; I cannot help.

[akstis-typer]

I was thinking about that issue and have a conclusion: we can't say nothing about encoding of attachments wothout metadata, but, we also cannot decode every single file without charset, using ISO-8859-1 encoding.
Maybe it's a better option to decode contents of files only, when we download them? We can use current user locale in glpi, or in browser, might use popup with encoding choosing when user hit download. Or we might not guess anything and doesn't decode text files attachments without charsets - and saving them like they are (returning contents as it is).
Because, when user downloads undecoded file - softwares (like vscode, notepad++) let the user choose encoding -> in that situation files will always be valid, but never automatically decoded.
I think that little popup, or setting that let user choose fallback encoding for file attachments will be nice :)

[akstis-typer]

I do not know/use docker at all; I cannot help.

And about that - I got it. User inside docker container (www-data) have uid and guid = 1000, however my www-data user, that have permissions to read and write to my folder, that got mounted inside docker container, have uid and guid = 33 - thats why composer responded with no permissions error.
Tests can be done either making directory owner 1000:1000, and execute run_test.sh with sudo -u 1000:1000, or adding to docker-compose-app.yml, after "app:" - user: "${HOST_UID:-1000}:${HOST_GID:-1000}" and export HOST_UID=[your user id] export HOST_GID=[your user group id] inside run_test.sh. Hope it'll help somebody :)

[akstis-typer]

Also, when I ran imap test I notice that original solution with $charset = mb_check_encoding($contents, 'UTF-8') ? 'UTF-8' : 'ISO-8859-1'; doesn't work either - tests not passed

[trasher]

Also, when I ran imap test I notice that original solution with $charset = mb_check_encoding($contents, 'UTF-8') ? 'UTF-8' : 'ISO-8859-1'; doesn't work either - tests not passed

Tests are currently all working on CI.

[Matsovagos]

I have the same problem also in glpi 11.0.4 when i receive an email from one platform. It goes to mailbox and everything appears good, but when glpi receiver makes it a ticket the Subject of the email witch is also the subject of the ticket shows gibberish. If i send an email direct to the mailbox lets say from outlook, ticket created will be readble