1. 20 Sep, 2018 2 commits
    • Arnaud Fontaine's avatar
      simulation: The parent SM may have several BLs as 'causality'. · 3f4c8e91
      Arnaud Fontaine authored
      Simulation Tree:
        SM_PPL
          AR(Inventory Accounting Transaction)
            SM_IAT(ledger=A)
            SM_IAT(ledger=B)
      
      Where SM_IAT.isBuildable() returns True iff:
        * SM_IAT(ledger=A): SM_PPL delivery state == 'started' (Shipped).
        * SM_IAT(ledger=B): SM_PPL delivery state == 'stopped' (Received).
      
      Defining this in a single BP lead to the following Business Links:
        * BL_PPL_started:
          - predecessor=trade/ordered
          - successor=trade/delivery_started
          - completed_state_list=['started']
          - trade_phase=trade/delivery
        * BL_IAT_ledger_A:
          - predecessor=trade/delivery_started
          - successor=trade/inventory_accounted
          - trade_phase=trade/inventory_accounting
          - predicate: ledger == A
      
        * BL_PPL_delivered:
          - predecessor=trade/ordered
          - successor=trade/delivered
          - completed_state_list=['stopped', 'delivered']
          - trade_phase=trade/delivery
        * BL_IAT_ledger_B:
          - predecessor=trade/delivered
          - successor=trade/inventory_accounted
          - trade_phase=trade/inventory_accounting
          - predicate: ledger == B
      
      This means that SM_PPL will have both BL_PPL_started and
      BBL_PPL_delivered Business Links as causality which was not handled
      by isBuildable.
      
      Another solution would have been to add this logic on the Builder
      'Simulation Select Method' but IMO this should not be done there.
      3f4c8e91
    • Yusei Tahara's avatar
  2. 19 Sep, 2018 1 commit
  3. 18 Sep, 2018 8 commits
  4. 17 Sep, 2018 18 commits
  5. 15 Sep, 2018 1 commit
    • Julien Muchembled's avatar
      Revert "Folder: call activate on the object instead of... · 1cd37609
      Julien Muchembled authored
      Revert "Folder: call activate on the object instead of portal_activities.activateObject in _recurseCallMethod()."
      
      This reverts commits 3d3ec3cb ((+ fixup), which
      broke recursion to objects that don't inherit ActiveObject, as explained in the
      docstring.
      
      I also think it was wrong in that default activate parameters disappear at the
      end of the transaction whereas _recurseCallMethod may activate itself to avoid
      creating to many activities at once. IOW, it's important that created
      activities are the same no matter where _recurseCallMethod splits the browsing.
      
      This change needed more review, as well as a unit test.
      1cd37609
  6. 14 Sep, 2018 6 commits
  7. 13 Sep, 2018 3 commits
  8. 12 Sep, 2018 1 commit