1. 05 Oct, 2015 4 commits
  2. 04 Oct, 2015 3 commits
  3. 02 Oct, 2015 3 commits
    • Cédric Le Ninivin's avatar
    • 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
    • Sebastien Robin's avatar
      simulation: remove concept of mirror movement · f915a2e0
      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
      f915a2e0
  4. 01 Oct, 2015 1 commit
  5. 30 Sep, 2015 1 commit
    • Vincent Pelletier's avatar
      ERP5Type.Base: Remove setDescription. · 45c1d70b
      Vincent Pelletier authored
      Documents should inherit from XMLObject, which already overloads this
      setter. As a result, this method is normally not used.
      The problem is that it gets called when calling
        newTempBase(
          description='foo'
        )
      which fails with:
        AttributeError: _setDescription
      because _setProperty finds setDescription and tries to call it, instead
      of setting description as a local property..
      45c1d70b
  6. 29 Sep, 2015 3 commits
  7. 28 Sep, 2015 4 commits
  8. 25 Sep, 2015 6 commits
  9. 24 Sep, 2015 11 commits
  10. 23 Sep, 2015 4 commits