1. 27 May, 2022 1 commit
    • Jérome Perrin's avatar
      AlarmTool: handle automatic solve with alarms owned by system user · 58f6b8dc
      Jérome Perrin authored
      Business templates are installed by system user, which is a special
      user not returned by getWrappedOwner. Because of this, the "fixing
      problems or activating a disabled alarm is not allowed" error was
      raised when checking if the owner of the alarm has manage portal
      permission on the alarm.
      
      This switches the implementation to explicit creation of the user
      when user id is the system user, so that we have a user with the
      permission to solve the alarm.
      58f6b8dc
  2. 04 May, 2022 3 commits
    • Arnaud Fontaine's avatar
      py2/py3: Make Products code compatible with both python2 and python3. · a17bb910
      Arnaud Fontaine authored
      Done through various 2to3 fixers (zope.fixers, modernize, future) and manual
      changes. This is a single commit so that we have a clearer picture of how code
      converted with my2to3 should look like.
      
      Except straightforward @implementer decorator 2to3 fixer, only product/ folder
      was considered as the goal was to be able to create an ERP5Site.
      
      * Use @implementer decorator introduced in zope.interface 3.6.0 (2010):
      
        The implements syntax used under Python 2.X does not work under 3.X, since it
        depends on how metaclasses are implemented and this has changed. Instead it
        now supports a decorator syntax (also under Python 2.X).
      
        Applied thanks to 2to3 `zope.fixers` package.
      
      * Use `six.moves` rather than `future` install_aliases() feature because the
        latter use unicode_literals and "wraps" module aliases so that unicode() are
        returned for text rather than str() (Python2 standard library). This notably
        breaks BusinessTemplate code which uses urllib quote() for filesystem paths...
      
      * No more unbound methods in python3 so use six.get_unbound_function().
      
      * dict.(iteritems,iterkeys,itervalues)() => six.\1(dict) thanks to `dict_six`
        2to3 fixer from `modernize`:
        $ python-modernize -w -f dict_six product/
      
      * Manually make sure that dict.{items,values,keys}() returns a real list when it
        is latter modified rather than a dict_{items,values,keys} (ensure_list()). By
        default, 2to3 blindly does list(dict.{items,values,keys}()) which is not
        acceptable from performances point of view. With my2to3, this will be possible
        to handle such case automatically.
      
      * Replace cStringIO.StringIO() by six.moves.cStringIO() (a module alias for
        cStringIO.StringIO() on py2 and io.StringIO() on py3).
      
      * Use six.text_type which maps to unicode() on py2 and str() on py3. This also
        makes a clearer difference between text and binary strings.
      
      * Replace map()/filter() with lambda function by list comprehension (this has
        the benefit to avoid casting to list for py3 as it returns iterators).
      a17bb910
    • Arnaud Fontaine's avatar
      ae3fe621
    • Arnaud Fontaine's avatar
      py3: Fix global definition. · 341dd5b7
      Arnaud Fontaine authored
      341dd5b7
  3. 03 May, 2022 1 commit
  4. 29 Apr, 2021 1 commit
  5. 23 Apr, 2021 1 commit
    • Arnaud Fontaine's avatar
      ERP5Workflow: DC Workflows are now ERP5 objects (!1378). · df85ef46
      Arnaud Fontaine authored
      This also moves all Configurator Workflows in workflow_module to portal_workflow
      (workflow_module was an implementation of Workflows based on ERP5 objects and
      not using DCWorkflow code).
      
      * Workflows are now defined on on portal_workflow._chains_by_type anymore but,
        as everything else, on the Portal Type itself.
      * portal_workflow can contain and work at the same time with legacy and new
        Workflows (ERP5Type/patches/DCWorkflow.py monkey-patching DCWorkflow classes
        to provide the same API).
      * Existing Workflow Scripts should work as they are and the code can be updated
        later on to take advantage of the new API:
        + With legacy implementation Workflow {Scripts,Transitions,Worklists,States}
          were in a Folder ({scripts,transitions,worklists,states} attribute) but
          all of these are now in the Workflow itself and their IDs are prefixed
          (PropertySheet-style), for example `script_`. Legacy attributes are
          provided in new implementation to call the new API.
        + When calling a Workflow Script, `container` was bound to its parent, namely
          WF.scripts (Folder) and a Workflow Script could call another. Now `container`
          is bound to the WF itself and Workflow Scripts are in a Workflow directly.
          New implementation `scripts` attribute handle such use case.
        + Override portal_workflow.__getattr__ so that a Workflow Script can call
          another one without prefix.
      * Worklist are Predicate: Worklist filter objects based on given criterions and
        thus it makes more sense for a Worklist to be a Predicate (albeit a Predicate
        with only Identity Criterion and nothing else).
        + Criterion Properties:
          * state_variable.
          * local_roles (SECURITY_PARAMETER_ID).
          * Any Workflow Variables with for_catalog == 1.
      
      erp5_performance_test:testWorkflowPerformance were ran to compare DCWorkflow
      and ERP5Workflow implementations and it seems to be about 4% slower with the
      new implementation (legacy: 7.547, 7.593, 7.618, 7.59, 7.514 and new: 7.842,
      7.723, 7.902, 7.837, 7.875).
      
      Work done by Wenjie Zheng, Isabelle Vallet, Sebastien Robin and myself.
      df85ef46
  6. 31 Mar, 2021 1 commit
  7. 11 Dec, 2020 1 commit
  8. 03 Dec, 2020 1 commit
  9. 24 Aug, 2020 1 commit
  10. 20 Jul, 2020 1 commit
  11. 02 Jul, 2020 2 commits
  12. 24 Jun, 2020 1 commit
  13. 23 Jun, 2020 1 commit
    • Arnaud Fontaine's avatar
      ZODB Components: Migrate Tools in Products.ERP5.Tool to erp5_core. · d2f87fd8
      Arnaud Fontaine authored
      Besides migrating Tools .py, this also moves the Tools themselves (portal_*):
       * Some of them were created before erp5_core being installed and this
         would not work anymore as their .py is now in erp5_core.
       * Some others were created after (via setupLastTool()) and this would not
         work neither as sub-objects may be installed by erp5_core.
      
      Add them to template_keep_path_list to prevent them from being re-created like
      ERP5Site.addERP5Tool() used to do (depend on 3180424b, 91393be2).
      
      Not migrated:
        * AlarmTool: Needed for upgrader.
        * CategoryTool, IdTool: Bootstrap.
        * TemplateTool, TrashTool: Business Template installation.
        * SolverTool: TypeProvider.
        * ContributionTool: Imported by Products.ERP5.Document.Document used in many places, will be done later.
        * NotificationTool: Imported by ERP5.Document.EmailDocument, will be done later.
      d2f87fd8
  14. 15 Jun, 2020 1 commit
  15. 03 Jun, 2020 1 commit
  16. 02 Jun, 2020 1 commit
  17. 01 Jun, 2020 1 commit
  18. 27 May, 2020 2 commits
  19. 07 May, 2020 3 commits
  20. 29 Apr, 2020 2 commits
  21. 24 Apr, 2020 1 commit
  22. 16 Apr, 2020 1 commit
    • Arnaud Fontaine's avatar
      erp5_certificate_authority: Certificate Authority Tool: All ERP5 objects... · 23b2b5fd
      Arnaud Fontaine authored
      erp5_certificate_authority: Certificate Authority Tool: All ERP5 objects *must* have have a Portal Type in Types Tool.
      
      And remove hack in erp5_promise which was creating a non-Portal Type class of
      portal_certificate_authority. Instead, add a depend on erp5_certificate_authority.
      `providesI*` accessors are now in BaseAccessorHolder rather than Base due to ZODB
      Components, this breaks reindexing (`AttributeError: providesIPredicate`).
      
      This gets rid of:
        WARNING ERP5Type.dynamic Cannot find a portal type definition for 'Certificate Authority Tool', trying to guess...
      23b2b5fd
  23. 08 Apr, 2020 1 commit
    • Arnaud Fontaine's avatar
      Tool/ContributionOpener: Moved its content (DirectoryFileHandler class) to... · af07ce4e
      Arnaud Fontaine authored
      Tool/ContributionOpener: Moved its content (DirectoryFileHandler class) to ContributionTool as this is not a Tool.
      
      As this is only used in ContributionTool, it does not seem necessary to create a separate
      module for that.
      
      Also:
        * Fix undefined variable `splitport`.
        * Use cStringIO instead of StringIO (as the rest of ContributionTool code does).
      af07ce4e
  24. 07 Apr, 2020 2 commits
    • Arnaud Fontaine's avatar
    • Arnaud Fontaine's avatar
      newTemp*() deprecation (1bce8563, 04b49859): Remove hack in... · 7bea7bb2
      Arnaud Fontaine authored
      newTemp*() deprecation (1bce8563, 04b49859): Remove hack in NotificationTool.sendMessage() not working with ZODB Components.
      
      When a Portal Type could not be found, sendMessage() was creating a temp_object
      instead (even when passing store_as_event=True) by calling newTempPORTAL_TYPE()
      and thus assuming a filesystem Document. So from now on, Portal Type must be
      available and thus sendMessage() will fail otherwise. Moreover, if store_as_event
      is True, this will no longer create a temp_object silently as it used to when
      the Portal Type is not available.
      
      This moves Mail Message Portal Type from erp5_crm to erp5_base as MailMessage_send
      (send() being called directly from sendMessage() for temp_object) is already
      in erp5_base. As this is only to allow creating temp_object, leave its Actions,
      Workflows and Constraint relying on erp5_crm API as they are.
      7bea7bb2
  25. 06 Apr, 2020 1 commit
  26. 03 Apr, 2020 1 commit
    • Arnaud Fontaine's avatar
      ZODB Components: erp5_simulation: Migrate Solvers and Testers from filesystem (MR !1093). · a7d6edba
      Arnaud Fontaine authored
      This moves portal_solver_processes from erp5_base to erp5_simulation as its
      Portal Type definition is already there and it was initially moved away from
      erp5_simulation presumably because erp5_simulation was for new Simulation at
      that time.
      
      Also, as delivery_causality_workflow uses portal_solver_processes, move it to
      erp5_simulation (along with delivery_causality_interaction). This required
      fixing Unit Tests to install erp5_simulation before erp5_trade (it already
      depended on it anyway).
      a7d6edba
  27. 10 Feb, 2020 1 commit
  28. 15 Jan, 2020 1 commit
  29. 20 Dec, 2019 2 commits
  30. 19 Dec, 2019 1 commit
  31. 10 Dec, 2019 1 commit