Commit 78d15e09 authored by Jérome Perrin's avatar Jérome Perrin

Fix mimetypes usage in handlers

cloudooo includes its own mimes.types, so that it does not depend on
system configuration and behave the same regardless of the underlying
system, but the embedded mime.types have to be loaded explicitly by
calling utils.loadMimetypeList() by each python process before using
mimetypes module.

This was not done for ooo and x2t handlers, so in practice they were
depending on the system mime.types and the tests were written to expect
the mimetypes from debian 10, but with debian 11 some mimetypes became
different ( for example .bmp extension was guessed as image/x-ms-bmp [1]
on debian 10 and image/bmp on debian 11 [2]),

Theses changes:
 - include mime.types from debian 10 [3], but keeping the extra mimetypes
   for  only-office documents (docy, ppty and xlsy) that were added in
   0bb5fbdc (x2t: add handler, 2016-09-22)
 - change the handlers to call utils.loadMimetypeList(), it was only
   strictly necessary for ooo handler, but do it as well in x2t for
   consistency.
 - adjust some tests in testX2tHandler, because now that we have
   loaded mimetypes database the mimetype of xlsy is returned in
   metadata, so we have "application/x-asc-spreadsheet" and not just "xlsy"
 - add a few more test for xlsy and docy, because the magic based test
   just verify that they are zip files, these new tests also make a few
   assertions on the content of the zip files

[1]: https://salsa.debian.org/debian/mime-support/-/blob/debian/3.62/mime.types#L677
[2]: https://salsa.debian.org/debian/media-types/-/blob/4.0.0/mime.types#L1804
[3]: https://salsa.debian.org/debian/mime-support/-/blob/debian/3.62/mime.types
parent f0c555b5
Pipeline #21447 failed with stage
in 0 seconds