An error occurred fetching the project authors.
  1. 29 Dec, 2014 1 commit
    • Julien Muchembled's avatar
      simulation: remove all activity dependencies for indexation of 'delivery' category · 653ff194
      Julien Muchembled authored
      They were useless since 'delivery' is indexed in ZODB, and this also fixes
      a bug causing local build to fail in the following conditions:
      - root document moved to a state that triggers a builder,
        whereas there's no simulation tree yet
      - the builder select method has a condition on the root simulation movement
      
      An example is building of task reports, when the ERP is overloaded.
      
      The reason was that in some cases, ERP5 tried to set 2 tags on the same
      reindexing activity (built: in updateMovementCollection & expand: in
      _updateSimulation), but there's actually no support for multi-valued tags
      and for CMFActivity, default activate parameters (here expand:) have lower
      precedence (see ActivateObject.activate). So another possible fix is to add
      built: to _localBuild after_tag.
      
      This commit also renames expand: into build:
      653ff194
  2. 04 Sep, 2014 1 commit
  3. 16 May, 2014 1 commit
  4. 24 Jan, 2014 1 commit
  5. 13 May, 2013 1 commit
  6. 26 Jan, 2013 1 commit
    • Julien Muchembled's avatar
      Simulation: index 'delivery' categories in ZODB · 0a8fbb36
      Julien Muchembled authored
      Use of catalog to get related simulation movements from delivery lines/cells is
      unreliable.
      
      Until now, for any new code written for simulation, we often had to be careful
      not to call getDeliveryRelatedValueList too early, usually by deferring code
      to activities with complicated dependencies. Race conditions are difficult to
      avoid by developping this way, because for a given delivery, there are
      potentially so many events that happen at the same time, involving:
      - simulation, amongst causality, expand, building, solving (including split)
      - alarms, user actions, external interfaces, chains of activities
      - several related deliveries and simulation trees
      
      This commit enables ZODB-indexing of related documents for 'delivery' base
      category, making getDeliveryRelatedValueList safe and fixing unlink of
      deleted delivery lines/cells.
      
      Existing activity dependencies are left unchanged because builders only uses
      catalog and local building needs to find all simulation movements.
      0a8fbb36
  7. 18 Dec, 2012 1 commit
  8. 05 Nov, 2012 1 commit
  9. 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
  10. 15 Jun, 2011 1 commit
  11. 08 Jun, 2011 1 commit
  12. 07 Jun, 2011 1 commit
    • Sebastien Robin's avatar
      on movement collections, use list of properties defined in rules · c64d4287
      Sebastien Robin authored
      Until now, we had in movement collections all possible properties
      found by _propertyMap for every movement. Now movement collections
      use list of properties defined in rules.
      
      This change was breaking some tests because not enough properties
      were expanded, so in the same time it is required to add more
      properties to progagate on several rules
      c64d4287
  13. 04 May, 2011 1 commit
  14. 04 Apr, 2011 1 commit
  15. 25 Mar, 2011 1 commit
  16. 16 Mar, 2011 1 commit
  17. 14 Mar, 2011 1 commit
  18. 11 Mar, 2011 5 commits
  19. 03 Mar, 2011 1 commit
  20. 02 Mar, 2011 1 commit
  21. 09 Nov, 2010 1 commit
  22. 19 Oct, 2010 1 commit
  23. 22 Sep, 2010 1 commit
  24. 06 Aug, 2010 2 commits
  25. 05 Aug, 2010 1 commit
  26. 03 Aug, 2010 4 commits
  27. 27 Jul, 2010 1 commit
  28. 12 Jul, 2010 1 commit
  29. 07 Jun, 2010 1 commit
  30. 30 May, 2010 1 commit
  31. 04 May, 2010 1 commit
  32. 19 Apr, 2010 1 commit