1. 10 Feb, 2020 1 commit
  2. 15 Jan, 2020 1 commit
  3. 20 Dec, 2019 2 commits
  4. 19 Dec, 2019 1 commit
  5. 10 Dec, 2019 1 commit
  6. 27 Nov, 2019 2 commits
  7. 31 Oct, 2019 1 commit
    • ZODB Components: Migrate Products.ERP5VCS (MR !973). · 2cff7d32
      Moved 'git_askpass' shell script to product/ERP5/bin (considering that this
      is a very short shell script which hasn't changed in 7 years, no need to move
      it to the ZODB which would require creating a temporary file...).
      After updating erp5_forge, you should delete 'product/ERP5VCS/' directory
      as this will only contain '.pyc' files.
      /reviewed-on !973
      Arnaud Fontaine committed
  8. 17 Sep, 2019 2 commits
    • Price per quantity per slice · 05f913a0
      This MR introduces a second way of calculating the base price of a resource using "Base Price Quantity Step".
      Currently, for a resource, we could define on a Supply Line "Quantity Steps",  and set a price for each of these steps. Then, depending on the quantity of the resource, the price of the unique matching step would apply.
      For exemple : 
      | Quantity Step Range | Price for the step|
      | 0 -> 10 | 10€ |
      | 11 -> 20 | 9€ |
      | 21 -> inf | 8€ |
      With the current method, for an Order of 15 products, the 2 range "11 -> 20" would apply, the unit price for the products would be 9€, and the total price would be 15*9 = 135€.
      The new method of calculating would apply the _Price for the step_ __to, and only to, all items of this step__. Which means, for an order of 15 products, the 10 first products would have a unit price of 10€, and the 5 next products would have a unit price of 9€, which makes in the end a total price of 145€, and a base price of 9.66€.
      /reviewed-on !896
      Nicolas Wavrant committed
    • DomainTool: list predicate values if more than one match · a032230c
      Also remove explanation_only which is dead code
      Nicolas Wavrant committed
  9. 13 Sep, 2019 1 commit
  10. 28 May, 2019 1 commit
  11. 24 May, 2019 1 commit
  12. 23 May, 2019 1 commit
  13. 22 May, 2019 1 commit
    • TemplateTool: upgrader first removes deprecated BT and then upgrade all BT · 8f270323
      For example, if property_sheet "prop" was moved from BT 1 to BT 2 and BT 1 doesn't exist anymore.
      Before this commit we have this order:
      1.  install BT 2 ("prop" exist and isn't touched)
      2. remove BT 1 ("prop" is removed)
      => at the end "prop" doesn't exist anymore
      After this commit we have this order:
      1. remove BT 1 ("prop" is removed)
      2. install BT 2 ("prop" is readded)
      => at the end "prop" exists and is OK
      /reviewed-on !866
      Thomas Gambier committed
  14. 21 May, 2019 2 commits
    • ERP5.Tool.CategoryTool, Folder: Resolve multi-inheritance from CopyContainer · c5cd1820
      These two classes inherits from two classes implementing CopyContainer API:
      - ours, via low-priority bases
      - another one, via higher-priority bases, because these classes need
        some non-ERP5 methods to override ERP5 methods.
      So after defining these classes, resolve inheritance priority by binding
      all CopyContainer methods provided by their ERP5 base class, overriding
      the ones provided by their non-ERP5 bases while still allowing their ERP5
      base class to override the CopyContainer method.
      Vincent Pelletier committed
    • IdTool: Add poisoning support. · 564cca95
      Allows for safe migration to another id generator, by preventing silent
      success of any piece of code still using the former generator, allowing
      its detection and resolution before duplicate ids are emitted.
      As a consequence, also allows on-demand and partial migration of id
      Vincent Pelletier committed
  15. 24 Apr, 2019 2 commits
    • test result: immediately redraft test result line on task failure · fe3bf27f
      Right now we have this scenario:
      - test result line is started
      - sometimes, runTestSuite fails (like timeout), failure is reported
        but test result line remains started (we don't know yet which
        line is associated with testnode)
      - when a test result line is "started" since more than 4 hours,
        test result line is redrafted
      - test can be reexecuted
      Speed up by removing the need of waiting alarm, by knowing which
      test result line is executed by which test node, and by redrafting
      immediately the test result line on test node failure
      Sebastien Robin committed
    • ERP5Type: Allow overriding _getAcquireLocalRoles . · 58d4ab8e
      Put auto-generated _getAcquireLocalRoles at the end of mro, removing it
      from Base.
      Also, document why it is treated specially here.
      Also, add _getAcquireLocalRoles methods on a few leaf classes whose
      instances fake being portal types, without actually being proper document
      instances. At least, the ones which are detected in unit tests. The
      proper fix would likely rather be to make them proper document classes,
      but this carries data migration concerns which go beyond the scope of
      this regression fix (_getAcquireLocalRoles was not possible to override
      Vincent Pelletier committed
  16. 19 Apr, 2019 1 commit
  17. 12 Apr, 2019 2 commits
  18. 18 Jan, 2019 1 commit
  19. 04 Sep, 2018 1 commit
  20. 02 May, 2018 1 commit
  21. 30 Jan, 2018 1 commit
  22. 24 Jan, 2018 1 commit
    • all: Avoid trivial direct calls to {recursiveI,i}mmediateReindexObject · ab9e0f93
      These methods must not be called synchronously:
      - they can break catalog by not being careful enough about other
        reindexations which may happen in parallel. See the serialization_tag
        mechanism for more.
      - indexation gets executed in the security context of the user causing the
        call, which may lead to an indexation result different from what happens
        when indexation happens with an all-accesses user.
      These lines of code (some even commented-out) give a bad example. Replace
      them with safe equivalents.
      Vincent Pelletier committed
  23. 11 Jan, 2018 1 commit
  24. 08 Nov, 2017 1 commit
  25. 03 Nov, 2017 1 commit
  26. 03 Oct, 2017 1 commit
  27. 28 Sep, 2017 1 commit
    • notification_tool: fix Unauthorized when sending message to person user cannot access · 82c51e7e
      When a user triggers `NotificationTool.sendMessage(recipient=user_id)` to a recipient she does not have access permission on, it now causes this problem (the caller context is a custom script with manager proxy role):
        Module Products.ERP5.Tool.NotificationTool, line 322, in sendMessage
          person_value = getUserValueByUserId(person)
        Module Products.ERP5.Tool.NotificationTool, line 291, in getUserValueByUserId
          return portal.restrictedTraverse(user['path'])
        Module OFS.Traversable, line 317, in restrictedTraverse
          return self.unrestrictedTraverse(path, default, restricted=True)
        Module OFS.Traversable, line 251, in unrestrictedTraverse
         - __traceback_info__: (['redacted_person_id'], 'person_module')
          next = guarded_getattr(obj, name)
      Unauthorized: You are not allowed to access 'person_module' in this context
      This is a regression caused by 62d8d3ac .
      That particular case was working before, because the person was looked up using [catalog]( https://lab.nexedi.com/nexedi/erp5/blob/882f0022c7af4f36c2f31643498ac0b5d82c2217/product/ERP5/Tool/NotificationTool.py#L321-322) so the proxy role from the caller script was taken in to account.
      Now, we can say that the approach suggested here is not correct and document that the current logged in user must have permission to access the person documents involved as sender or recipient in the notification.
      Then, if we need to send message to persons the current user does not have access permission, instead  of using:
      just do:
      but the later does not allow for using activities.
      /cc @vpelletier @gabriel 
      /reviewed-on !395
      Jérome Perrin committed
  28. 27 Sep, 2017 1 commit
  29. 26 Sep, 2017 1 commit
  30. 25 Sep, 2017 1 commit
    • SimulationTool: Remove input/output perimeter definition. · 8b6865ae
      As per Jérome, who implemented the test, it was written to test the
      current state rather than testing the desired outcome. And it makes
      little sense to have (and test for) 100 being present in both debit and
      credit columns ("normal" lines), and 0 to be present in the stat line.
      Update test to check for a more consistent outcome.
      Acked-by: Jérome Perrin <jerome@nexedi.com>
      Vincent Pelletier committed
  31. 15 Sep, 2017 3 commits
  32. 30 Aug, 2017 1 commit