1. 19 Apr, 2021 4 commits
    • Jérome Perrin's avatar
      ERP5Type: don't publish workflow methods · b69cd538
      Jérome Perrin authored
      Wrapping a method in a workflow method should not change the
      publishable state the method.
      If the original method is not publishable, wrapping it in a workflow
      method should not make it publishable.  If the original method is
      publishable, then the wrapped method should still be publishable.
      
      This was always intended to work like this, as we can see in the code
      comment in `WorkflowMethod.__init__` but was not properly tested and got
      broken at some point.
      
      It's important to restore the behavior, because workflow methods such as
      `validate` should not be published, users must only be able to use the
      user interface transitions freely, workflow methods transitions are
      only available if developer expose them in a script - and perform the
      necessary consistency and security checks in that script.
      b69cd538
    • Jérome Perrin's avatar
      core: remove guards on workflow methods · 086c3df4
      Jérome Perrin authored
      086c3df4
    • Jérome Perrin's avatar
      testSecurity: adjust test_workflow_transition_protection · 7d6df387
      Jérome Perrin authored
      Only "user action" methods needs a security declaration.
      7d6df387
    • Jérome Perrin's avatar
      More tests for CRM "Create New Event" and "Create Response" dialogs · b8e4bc38
      Jérome Perrin authored
      In e559ecd5 ([erp5_crm] Activate actions for ERP5JS, 2019-09-25) we introduced
      a regression, support for erp5_xhtml_style got broken in "Create Response"
      when enabling ERP5JS.
      
      It was fixed later in 3125590f (fixup! [erp5_crm] Activate actions for ERP5JS,
      2020-10-23).
      
      This extends test coverage for:
       - "Create Response" in erp5_xhtml_style
       - "Create New Event" in both ERP5JS and erp5_xhtml_style
      
      See merge request nexedi/erp5!1397
      b8e4bc38
  2. 16 Apr, 2021 1 commit
    • Jérome Perrin's avatar
      xhtml_style: fix rendering of standard_error_message when site title is not ASCII · 8fffd3f8
      Jérome Perrin authored
      When rendering error page, the default header_title is computed in global_definitions
      and this is done by concatenating string:ERP5 (which is unicode) and the
      title of the portal (which is an UTF-8 encoded string), which causes an
      UnicodeDecodeError, because the portal title was decoded as ASCII.
      
      Because header_title is usually an UTF-8 encoded string, also use an UTF-8
      encoded string for 'ERP5' default value.
      8fffd3f8
  3. 15 Apr, 2021 8 commits
  4. 14 Apr, 2021 9 commits
  5. 13 Apr, 2021 6 commits
  6. 12 Apr, 2021 3 commits
  7. 09 Apr, 2021 4 commits
  8. 07 Apr, 2021 1 commit
  9. 06 Apr, 2021 1 commit
  10. 02 Apr, 2021 2 commits
  11. 01 Apr, 2021 1 commit