1. 19 Apr, 2019 1 commit
  2. 27 Jul, 2018 1 commit
    • Sebastien Robin's avatar
      simulation: solve random solving issues in a cluster environment · 924f20fa
      Sebastien Robin authored
      Before, when solving a solver, parsing sub objects of solver_process was done directly synchronously
      in solver_workflow. And we had the case where you have parallel transactions solving a solver,
      each of theses transactions see remaining solver not in solved state, but once all transaction are
      finished, all solver are solved. This could lead to the case where solver_process is never moved
      to succeeded. Instead of using serialize (which may lead to conflicts), just use activities in queue
      with a serialization tag.
  3. 30 Nov, 2017 1 commit
  4. 27 Nov, 2017 1 commit
  5. 19 Oct, 2017 1 commit
  6. 11 May, 2017 2 commits
    • Arnaud Fontaine's avatar
      Prevent 'draft' Solver Process from being created when there is already a 'solving' one (#KH-1107). · 2e2f59f7
      Arnaud Fontaine authored
        1. 'Solve Divergences' action:
           => Display Delivery_viewSolveDivergenceDialog.listbox:
              -> Delivery_getSolverDecisionList
                 -> Delivery_getSolverProcess => create Solver Process in 'draft' state and build Solver Decisions.
        2. Clicking 'Update' button updates Solver Decisions.
        3. Click 'Solve Divergences' button after either 'Adopt Prevision' or 'Accept Decision'.
           => SolverProcess.solve():
              Solver Process transit to 'solving' state and 'solve' Activity is created.
      Before this Activity is executed, user can still select 'Solve Divergences'
      action and this will create another 'Solver Process' as the current one is not
      in 'draft' state anymore. Moreover, another user can still 'Adopt Prevision'
      (while the first user selected 'Accept Decision') and this will be actually be
      applied despite the first user choice.
      Instead, create Solver Process when transiting to 'diverged' state and do not
      display 'Solve Divergences' button nor allow access to 'Solve Divergences
      Dialog' (Delivery_viewSolveDivergenceDialog) if there is a Solver Process in
      'solving' state.
    • Arnaud Fontaine's avatar
      erp5_simulation: Display Divergence dialog even if there is nothing to solve... · 66cc5bfa
      Arnaud Fontaine authored
      erp5_simulation: Display Divergence dialog even if there is nothing to solve (same as legacy Simulation Dialog).
      This fixes the following Site Error when there is no Divergence to solve:
        AttributeError: 'NoneType' object has no attribute 'SolverProcess_getSolverDecisionList'
      This may happen if user selects 'Solve Divergence' Action and solve
      Divergences, then immediately goes back and selects again this action
      whereas there is actually no Divergence to solve.
  7. 06 Jun, 2016 1 commit
    • Julien Muchembled's avatar
      BT: dummy copy to preserve history · 428310a2
      Julien Muchembled authored
      We should have done before committing 76ecef89
      but doing it now with a dummy merge also works.
      Unfortunately, this is not really useful for blame, because all lines are
      rewritten, at least to remove the trailing '\n'.
      Files that have already been modified in 'master' branch are excluded.
  8. 07 Mar, 2016 1 commit
  9. 18 Feb, 2016 2 commits
    • Arnaud Fontaine's avatar
      simulation: tested_property_title field was missing. · 12777c46
      Arnaud Fontaine authored
      Followup of: "simulation: improve equivalence testers explanations messages".
    • Sebastien Robin's avatar
      simulation: improve equivalence testers explanations messages · b4361eb8
      Sebastien Robin authored
      With latest simulation, the explanation given to user when solving a
      divergence was not good enough :
      - Property ids were displayed without possibility to display
        business word (like displaying 'stop_date' instead of
        'Delivery Date'
      - Some message was displayed in the solve divergence dialog whatever
        was the equivalence tester behind. Therefore, customizations of
        messages made a equivalence tester level were not displayed to user
      Therefore, following was done:
      - in solve divergence dialog, include the message generated by the
        equivalence tester
      - use tested_property_title to allow using business words to describe
        properties having divergence
      - most equivalence testers are written in a way to evaluate divergence
        on a single property. To have better UI configuration of such equivalence
        testers, change tested_property and tested_property_title properties
        type from "lines" to "string". This required to add some backward
        compatible code.
      - use Variation Divergence Tester to show a case of an equivalence
        tester using different properties. For this, add a property sheet
        dedicated to multi properties equivalence testers
      - update propertysheets to allow translating tested_property_title
  10. 01 Feb, 2016 1 commit
    • Sebastien Robin's avatar
      simulation: use proxy roles and guards for Delivery_getSolverProcess · fb47b9ce
      Sebastien Robin authored
      Solve divergence dialog was raising unauthorized error when new solver process was created
      by this script (when called with someone who was not manager). Therefore use proxy role and
      protect call with "View" permission. View is used instead of modify portal content since we could
      imagine cases where user might need to solve divergence even though is has no right to modify
  11. 28 Jan, 2016 1 commit
    • Arnaud Fontaine's avatar
      erp5_core: Fix ListMode view for ListBox with several tabs. · f6a79a1a
      Arnaud Fontaine authored
      1. On Tab1, from PurchaseSupply_view, click on 'Purchase Supply Lines':
         This Python Script initialise 'list_mode_proxy_selection' with the
         above 2 GET parameters and then displays PurchaseSupply_view.listbox
         indirectly but current Form is Base_viewListModeRenderer.
      2. On Tab2, from SaleSupply_view, click on 'Sale Supply Lines':
         This Python Script initialise 'list_mode_proxy_selection' with the
         above 2 GET parameters and then displays SaleSupply_view.listbox
         indirectly but current Form is Base_viewListModeRenderer.
      3. On Tab1, filter Purchase Supply Lines.
         As proxy_form_id and proxy_field_id are not given, then
         Base_viewListModeRender fallbacks on 'list_mode_proxy_selection'
         values to find out the Form ID to be called and wrongly display
         SaleSupply_view.listbox (2.).
  12. 01 Dec, 2015 1 commit
  13. 09 Nov, 2015 1 commit
  14. 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
  15. 16 Sep, 2015 1 commit
  16. 10 Sep, 2015 1 commit
  17. 27 Apr, 2015 1 commit
  18. 28 Aug, 2013 1 commit
  19. 04 Jun, 2013 1 commit
  20. 15 Mar, 2013 1 commit
  21. 21 Feb, 2013 1 commit
  22. 29 Jan, 2013 1 commit
  23. 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() 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
      - 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.
  24. 28 May, 2012 1 commit
  25. 22 May, 2012 1 commit
  26. 09 Apr, 2012 1 commit
  27. 26 Jan, 2012 1 commit
  28. 24 Jan, 2012 2 commits
  29. 19 Jan, 2012 2 commits
  30. 11 Jan, 2012 1 commit
  31. 23 Dec, 2011 1 commit
  32. 15 Sep, 2011 1 commit
  33. 11 Aug, 2011 1 commit
  34. 12 Jul, 2011 2 commits
  35. 28 Jun, 2011 1 commit