1. 11 Apr, 2023 1 commit
  2. 10 Nov, 2022 1 commit
  3. 09 Nov, 2022 3 commits
  4. 04 Nov, 2022 1 commit
  5. 03 Nov, 2022 1 commit
  6. 31 Aug, 2022 3 commits
  7. 13 May, 2022 1 commit
    • Jérome Perrin's avatar
      Fix mimetypes usage in handlers · 78d15e09
      Jérome Perrin authored
      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
      78d15e09
  8. 11 Jan, 2022 1 commit
  9. 28 Apr, 2021 1 commit
    • Jérome Perrin's avatar
      openoffice: fix psutil usage in _releaseOpenOfficePort · 0b5ff71a
      Jérome Perrin authored
      This uses psutil.process_iter to iterate on all processes, but in the meantime
      some process might terminate.
      
      As we could observe in the logs:
      
          2021-04-26 12:53:02 - Cloudooo - DEBUG - Stop Pid - 15816
          Exception in thread Thread-1:
          Traceback (most recent call last):
            File "python2.7/lib/python2.7/threading.py", line 801, in __bootstrap_inner
              self.run()
            File "cloudooo-repository/cloudooo/handler/ooo/monitor/request.py", line 60, in run
              self.openoffice.restart()
            File "cloudooo-repository/cloudooo/handler/ooo/application/application.py", line 79, in restart
              self.stop()
            File "cloudooo-repository/cloudooo/handler/ooo/application/openoffice.py", line 169, in stop
              self._releaseOpenOfficePort()
            File "cloudooo-repository/cloudooo/handler/ooo/application/openoffice.py", line 122, in _releaseOpenOfficePort
              if process.exe() == join(self.office_binary_path, self._bin_soffice):
            File "psutil-5.8.0-py2.7-linux-x86_64.egg/psutil/__init__.py", line 660, in exe
              exe = self._proc.exe()
            File "psutil-5.8.0-py2.7-linux-x86_64.egg/psutil/_pslinux.py", line 1688, in exe
              raise NoSuchProcess(self.pid, self._name)
          NoSuchProcess: psutil.NoSuchProcess process no longer exists (pid=19382)
      
      Update to catch and ignore such exceptions, and minor refactorings such as:
       - Not calculate the path of openoffice binary in the loop, this is not
         supposed to change.
       - Remove reference to lsof in logged message, this does not use lsof.
       - Catch all exceptions.
      0b5ff71a
  10. 29 Mar, 2021 1 commit
    • Jérome Perrin's avatar
      manager/getAllowedExtensionList: use explicit extensions in ERP5 legacy mode · be6c35c0
      Jérome Perrin authored
      In python2, mimetypes module was not deterministic and this snippet:
      
          import mimetypes; print(mimetypes.guess_extension("text/html"))
      
      use to be ".html" on python 2.7.14, but is ".htm" on python 2.7.18
      
      Similarly:
      
          import mimetypes; print(mimetypes.guess_extension("application/msword"))
      
      was ".doc" on 2.7.14 and ".dot" on 2.7.18 (this was in my observations, this
      does not look deterministic as it is iterating on a dict, maybe this behaviour
      is not always same)
      
      For html conversion engine, ERP5 expect that the extension for text/html is
      .html, not .htm. Some tests also expect that the conversion for word is .doc so
      to keep compatibility with extensions used in ERP5 compatibility mode, define
      explicitly these two extensions instead of depending on python standard library.
      be6c35c0
  11. 01 Jun, 2020 1 commit
  12. 25 May, 2020 1 commit
  13. 18 May, 2020 1 commit
  14. 14 May, 2020 1 commit
  15. 06 May, 2020 1 commit
  16. 05 May, 2020 1 commit
  17. 02 Jan, 2020 1 commit
  18. 30 Dec, 2019 1 commit
  19. 27 Dec, 2019 1 commit
  20. 13 Mar, 2019 1 commit
  21. 21 Sep, 2018 1 commit
  22. 18 Sep, 2018 3 commits
  23. 14 Sep, 2018 4 commits
  24. 03 Aug, 2018 1 commit
  25. 26 Feb, 2018 7 commits