1. 10 Jan, 2024 15 commits
    • Jérome Perrin's avatar
      py3: do not enable NEO test yet 🚧 · 1d03b670
      Jérome Perrin authored
      at this point they all fail after long timeouts, because neo does not
      support py3 yet
      1d03b670
    • Jérome Perrin's avatar
      ERP5 PY3: WIP init_user fix · ac291f55
      Jérome Perrin authored
      ac291f55
    • Jérome Perrin's avatar
      WIP ERP5: XXX dumps() parameter for longrequest promise 🚧 · a011d105
      Jérome Perrin authored
      Not sure why it was OK on python2 and not sure if this has to be done
      or the promise code needs to cast the results of getConfig()
      a011d105
    • Jérome Perrin's avatar
      ERP5 py3: WIP changes · a690f671
      Jérome Perrin authored
      a690f671
    • Arnaud Fontaine's avatar
      XXX-zope4py3: zodbpickle: Dirty hack to have encoding sets to utf-8. · b9e2c43f
      Arnaud Fontaine authored
      Otherwise it fails with the following exception because of non-ASCII characters
      (`[A-Z&é@{]{3,7})`) (see unconvert()) below):
      
        => erp5_core/PathTemplateItem/portal_preferences/default_site_preference.xml
           File "zodbpickle-2.0.0-py3.7-linux-x86_64.egg/zodbpickle/pickle_3.py", line 844, in load
              dispatch[key[0]](self)
           File "zodbpickle-2.0.0-py3.7-linux-x86_64.egg/zodbpickle/pickle_3.py", line 1035, in load_short_binstring
              self.append(self.decode_string(data))
           File "zodbpickle-2.0.0-py3.7-linux-x86_64.egg/zodbpickle/pickle_3.py", line 989, in decode_string
              return value.decode(self.encoding, self.errors)
        UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 19: ordinal not in range(128)
      b9e2c43f
    • Jérome Perrin's avatar
      software/slapos-sr-testing: add erp5-py3 · 0696b13b
      Jérome Perrin authored
      0696b13b
    • Bryton Lacquement's avatar
    • Kazuhiko Shiozaki's avatar
    • Kazuhiko Shiozaki's avatar
      7e716c29
    • Jérome Perrin's avatar
    • Jérome Perrin's avatar
      0b797df4
    • Jérome Perrin's avatar
      ERP5: rework frontend instance parameter · 08fb69c0
      Jérome Perrin authored
      This change the format or the (mostly) unused frontend parameter to
      support requesting more than one frontend and also enable the request of
      a frontend by default, so that requesting a frontend separately is no
      longer needed.
      
      The `frontend` parameter now also supports requesting frontends for
      specific paths on the ERP5 backend, the example below requests a
      frontend serving directly a web site, with the necessary rewrite rules:
      
      ```js
      {
        "frontend": {
          "default": {
            "internal-path": "/erp5/web_site_module/renderjs_runner/"
          }
        }
      }
      ```
      
      The example below requests a default frontend to the erp5 root, to
      access the ZMI or erp5_xhtml_style interface and two web sites:
      
      ```js
      {
        "frontend": {
          "default": {},
          "erp5js": {
            "internal-path": "/erp5/web_site_module/renderjs_runner/"
          },
          "crm": {
            "internal-path": "/erp5/web_site_module/erp5_officejs_support_request_ui/"
          }
        }
      }
      ```
      
      The example below has an explicit definition of the zope families using
      `zope-partition-dict` parameter, because there is more than one zope
      family, no frontend is requested by default:
      
      ```js
      {
        "zope-partition-dict": {
          "backoffice": {
            "family": "backoffice"
          },
          "web": {
            "family": "web"
          },
          "activities": {
            "family": "activities"
          }
        }
      }
      ```
      
      Continuing this example, to have frontends for backoffice and web
      families, the frontend request can specify the families, like it is
      demonstrated in the example below. In this example, we don't specify an
      entry for "activities" family, so no frontend will be requested for
      this family.
      
      ```js
      {
        "frontend": {
          "backoffice": {
            "zope-family": "backoffice"
          },
          "web": {
            "zope-family": "web",
            "internal-path": "/erp5/web_site_module/web_site/"
          }
        }
        "zope-partition-dict": {
          "backoffice": {
            "family": "backoffice"
          },
          "web": {
            "family": "web"
          },
          "activities": {
            "family": "activities"
          }
        }
      }
      ```
      08fb69c0
    • Jérome Perrin's avatar
      random: expose hashed passwords in recipe options · 03a668ee
      Jérome Perrin authored
      Directly expose all passlib.hash supported hashes, using a `passwd-`
      prefix. For example, to access `sha256_crypt`, use `passwd-sha256-crypt`
      option name.
      
        [secret]
        recipe = slapos.cookbook:generate.password
      
        [config-file]
        hashed-password = ${secret:passwd-sha256-crypt}
      03a668ee
    • Jérome Perrin's avatar
      5f752681
    • Jérome Perrin's avatar
      software/erp5/test: use short partition references · 48ea189d
      Jérome Perrin authored
      These partition references should be kept short, they are a mechanism
      to use a short path for unix sockets, because unix socket paths can not
      exceed 108 characters.
      
      When running the test in theia, this was causing errors:
      
         # [ALERT]    (100453) : config : parsing [/srv/slapgrid/slappart15/srv/runner/instance/slappart7/tmp/inst/with-max-rlimit-nofile6/etc/haproxy.cfg:37] : log : socket path '/srv/slapgrid/slappart15/srv/runner/instance/slappart7/tmp/inst/with-max-rlimit-nofile6/var/run/log.sock' too long (max 97
      48ea189d
  2. 05 Jan, 2024 1 commit
    • Kirill Smelkov's avatar
      format-json, test: Don't force ASCII · cd75648d
      Kirill Smelkov authored
      Currently, due to ensure_ascii=True default of json.dumps, we are
      insisting on our JSON schemas to be ascii-only and all other characters
      to be represented by \uxxxx escapes. So far this was not problematic as
      all our schemas contains only ASCII characters, but upcoming
      ors-amarisoft changes want to use e.g. "→" symbol:
      
          https://lab.nexedi.com/kirr/slapos/blob/b51f5523/software/ors-amarisoft/software.cfg.json#L15
      
      which currently results in failure of json-schema test:
      
          FAIL: test_ors-amarisoft_software_cfg_json_format (slapos.test.test_json_schema.TestJSONSchemaValidation)
          ...
      
          First differing element 14:
          '      "title": "\\u2192  eNB/gNB | Radio Unit",'
          '      "title": "→  eNB/gNB | Radio Unit",'
      
      And in general, in 2023 I think there is no reason to insist on our schemas to
      be ASCII-only: say if one wants to describe something about "α" parameter. It
      would be good to use that α character directly and seeing it in the editor,
      instead of using escapes all the time.
      
      As indicated by below stackoverflow answer "JSON spec requires UTF-8 support by
      decoders": https://stackoverflow.com/a/594881/9456786 , and indeed checking
      JSON specification also confirms that by default JSON decoders shall use UTF-8:
      
          https://datatracker.ietf.org/doc/html/rfc7159#section-8.1
      
      This way, I think, we can switch to UTF-8 safely.
      
      /reviewed-by @jerome, @lu.xu
      /reviewed-on nexedi/slapos!1498
      cd75648d
  3. 04 Jan, 2024 1 commit
  4. 02 Jan, 2024 3 commits
  5. 29 Dec, 2023 1 commit
  6. 28 Dec, 2023 3 commits
  7. 25 Dec, 2023 8 commits
  8. 20 Dec, 2023 1 commit
    • Titouan Soulard's avatar
      software/rapid-cdn: avoid RegExp to validate hostnames · 11336190
      Titouan Soulard authored
      Using RegExp to validate hostnames is a bad practice, and has a lot of reasons to be wrong.
      On top of that, the JSON Schema specification allows, since draft 7, to validate hostnames
      against an IDN hostname, by using the `idn-hostname` format.
      
      With these changes, IDN are now supported (.рф and .中國 for instance), and long TLD
      should not be a problem anymore.
      11336190
  9. 19 Dec, 2023 1 commit
  10. 18 Dec, 2023 2 commits
  11. 15 Dec, 2023 1 commit
  12. 14 Dec, 2023 3 commits