An error occurred fetching the project authors.
  1. 04 May, 2022 1 commit
    • 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
  2. 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
  3. 07 Jan, 2016 1 commit
  4. 29 Dec, 2015 1 commit
  5. 02 Oct, 2015 1 commit
    • Sebastien Robin's avatar
      simulation: remove concept of mirror movement (continue) · e8524a08
      Sebastien Robin authored
      Remove broken concept of Mapping Properties that was used on legacy
      simulation. We do not want to use this concept any more, any mapping
      should be done by rule themself. Removing mapping properties leads
      to more generic concepts and much simpler code.
      
      With legacy simulation, in case of returned sale packing list
      (in case we want to invoice in same sale invoice usual sale packing
      list and returned sale packing list) :
      AR (delivering_rule):
        -> SM (source/A, destination/B)
          -> AR (invoicing_rule, having mapped_property mapping
                 source to destination and vice versa)
            -> SM (source/A, destination/B) builders and solvers
               where doing sm.getMappedProperty('source') which was equivalent
               to sm.getProperty('destination'), thus the mapping was done
               in live time
      
      Now in such case, we should implement mapping directly at rule level,
      and this should give:
      AR (delivering_rule):
        -> SM (source/A, destination/B)
          -> AR (invoicing_rule, reversing source and destination)
            -> SM (source/B, destination/A) here we directly have properties
               we wish, no need of hacks on builders and solvers
      e8524a08
  6. 16 Oct, 2014 1 commit
  7. 03 Oct, 2012 1 commit
    • Julien Muchembled's avatar
      Simulation: splitted expand, performance improvements and bugfixes · 5c09e2e2
      Julien Muchembled authored
      All interactions and activity tags are reviewed to fix bugs like duplicated
      root applied rules, and also reduces the amount of duplicated/useless work, e.g:
      - Simulation trees are not expanded anymore when simulated objects are modified.
      - 'expand' activities are merged (i.e. dropped) with any other 'expand' activity
        for an ancestor.
      New implementation exposes new API that hides much complexity to the developper
      about activity dependencies.
      
      By default, expand() now automatically defers any work if the current
      transaction takes too long time. This method also gains a parameter to
      explicitely choose when to expand, which is often important in unit tests or
      solvers. In particular, when postponing work, it takes care of setting proper
      activity dependencies.
      - If you have any code requiring to expand everything immediately, you'll have
        to replace 'expand()' by 'expand(expand_policy="immediate")'.
      - On the contrary, you should replace any 'activate().expand()' by
        'expand(expand_policy="deferred")'.
      expand() still accepts activity parameters for any extra needs.
      
      In causality workflow, 'building' state is clarified and now means
      « delivery may diverge but we can't know now ». A delivery remains in draft
      as long as it does not contain any movement built from simulation.
      After init/clone/builder/etc. scripts used to call 'startBuilding' &
      'updateCausalityState': this calls must be removed since only
      SimulatedDeliveryBuilder should take care of move to 'building' state and
      workflows now triggers 'updateCausalityState'.
      
      Disguised interactions have been unhardcoded and either deleted, or moved to
      appropriate interaction workflows, which have been reorganized. Those
      that triggers update of portal_workflow can be easily customized or disabled.
      
      New API:
      - updateSimulation() on deliveries and subscription items. It takes care of
        creating root applied rule, expanding and reindexing parts of simulation
        trees. It somehow replaces:
        - Delivery_updateSimulation
        - Delivery_updateAppliedRule
        - Delivery.applyToDeliveryRelatedMovement
        - Delivery.updateAppliedRule
        - Delivery.expand
        - Delivery.expandRuleRelatedToMovement
        - SubscriptionItem.expand
        - SubscriptionItem.updateAppliedRule
      - Delivery.localBuild() is the new way to do local building and replaces
        Delivery_expandAndBuild. Private method Delivery._localBuild replaces
        Delivery_buildOnComposedDocument.
      - Simulation Movements that are being built by a builder are reindexed with
        the following tag: 'built:<delivery_path>'. Any after_path_and_method_id
        dependency against 'related_simulation_movement_path_list' and reindexing
        methods should be replaced by this after_tag.
      
      After builder scripts used to confirm the delivery in a separate activity,
      which was useless.
      5c09e2e2
  8. 22 May, 2012 1 commit
    • Julien Muchembled's avatar
      Fix Trade Model Solver that wrongly skipped some TM related simulation movements · a96fa2a8
      Julien Muchembled authored
      This fixes a regression in recent commit 6e758ade
      
      The following line:
      
        simulation_movement_list = delivery_dict.get(movement) or \
          movement.getDeliveryRelatedValueList()
      
      didn't work because the loop that fills delivery_dict does not necessarily
      find all related simulation movements for every key.
      
      New code is a little complicated because it tries to not call
      getDeliveryRelatedValueList() when 'movement' is not related to trade model.
      a96fa2a8
  9. 03 May, 2012 2 commits
  10. 06 Dec, 2011 1 commit
  11. 27 Jul, 2011 1 commit
  12. 22 Jun, 2011 1 commit
  13. 05 Aug, 2010 1 commit
  14. 15 Jul, 2010 1 commit
    • Sebastien Robin's avatar
      sync with trunk@37114 · c1ae57b0
      Sebastien Robin authored
      Conflicts:
      	bt5/erp5_base/bt/revision
      	bt5/erp5_simulation/DocumentTemplateItem/InvoiceSimulationRule.py
      	bt5/erp5_simulation/bt/revision
      	bt5/erp5_trade/SkinTemplateItem/portal_skins/erp5_trade/Base_viewTradeFieldLibrary.xml
      	bt5/erp5_trade/bt/change_log
      	bt5/erp5_trade/bt/revision
      	products/ERP5/Document/BusinessPath.py
      	products/ERP5/Document/SimulationMovement.py
      	products/ERP5/Document/TradeCondition.py
      	products/ERP5/Document/TradeModelLine.py
      	products/ERP5/bootstrap/erp5_mysql_innodb_catalog/bt/revision
      	products/ERP5Type/ERP5Type.py
      
      git-svn-id: https://svn.erp5.org/repos/public/erp5/sandbox/amount_generator@37129 20353a03-c40f-0410-a6d1-a30d3c3de9de
      c1ae57b0
  15. 06 Jul, 2010 2 commits
  16. 02 Jul, 2010 1 commit
  17. 01 Jul, 2010 1 commit
  18. 25 Jun, 2010 1 commit
  19. 10 May, 2010 1 commit
  20. 23 Mar, 2010 3 commits
  21. 17 Mar, 2010 1 commit
  22. 10 Mar, 2010 1 commit
  23. 10 Feb, 2010 1 commit
  24. 04 Feb, 2010 1 commit
  25. 21 Jan, 2010 1 commit
  26. 22 Dec, 2009 1 commit
  27. 17 Dec, 2009 1 commit
  28. 15 Dec, 2009 1 commit
  29. 14 Dec, 2009 1 commit
  30. 17 Nov, 2009 1 commit
    • Sebastien Robin's avatar
      - the possibility to pass --enable_full_indexing=portal_skins in · 2dd6ad08
      Sebastien Robin authored
       order to make optimisation configuration in unit test
      - isIndexable is not a property any more, it is a ConstantGetter
       instance, so it works like a property and like a method
      - same thing for isPredicate, isTemplate, isDelivery... we can
       start moving using only methods.
      - do not define isTemplate, isDelivery... when it is already
        available thanks to inheritance
      - new methods generated for all ERP5 objects : provides[InterfaceName].
       For instance, "providesIMovement()" will return True or False for
       any ERP5 object.
      - new method "is[Group]Type" generated for all ERP5 objects. The group
       here is group of portal types (like getPortalDeliveryTypeList()). So
       on any ERP5 object, you can do "isDeliveryType()", and this will
       returns True or False.
      - add tests
      
      git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@30704 20353a03-c40f-0410-a6d1-a30d3c3de9de
      2dd6ad08
  31. 07 Nov, 2009 2 commits
  32. 04 Nov, 2009 1 commit
  33. 01 Jun, 2009 1 commit
  34. 05 Feb, 2007 1 commit
  35. 02 Feb, 2007 1 commit