1. 25 Feb, 2019 1 commit
  2. 22 Feb, 2019 2 commits
  3. 21 Feb, 2019 2 commits
  4. 20 Feb, 2019 4 commits
  5. 18 Feb, 2019 3 commits
  6. 16 Feb, 2019 1 commit
  7. 15 Feb, 2019 7 commits
  8. 14 Feb, 2019 3 commits
  9. 13 Feb, 2019 5 commits
  10. 12 Feb, 2019 1 commit
    • Arnaud Fontaine's avatar
      ZODB Components: Likewise Document, add Mixin (erp5.component.mixin) and... · e84d2b51
      Arnaud Fontaine authored
      ZODB Components: Likewise Document, add Mixin (erp5.component.mixin) and Interface (erp5.component.interface).
      
      * One Mixin/Interface class per ZODB Component.
        => Already the case for FS Mixin, not for Interfaces.
      * ZODB Components module name ('reference' property) and class name:
        + Mixin: FooMixin.
        + Interface: IFoo.
      
      Rationale:
        + Avoid current FS hacks: registry (Mixins, mixin_class_registry) or import
          all classes explicitly in __init__.py (Products.ERP5Type.interfaces).
        + Consistent naming.
        + Consistent with ZODB Documents Components.
      
      Also, modify pylint checker to handle Zope Interfaces:
        + E: 4, 0: Inheriting 'Interface', which is not a class. (inherit-non-class)
        + E: 5, 2: Method has no argument (no-method-argument)
      e84d2b51
  11. 11 Feb, 2019 3 commits
  12. 08 Feb, 2019 1 commit
  13. 07 Feb, 2019 4 commits
  14. 05 Feb, 2019 3 commits
    • Julien Muchembled's avatar
      4b7acaa7
    • Julien Muchembled's avatar
      CMFActivity: remove old skin if any · afaa9d19
      Julien Muchembled authored
      afaa9d19
    • Julien Muchembled's avatar
      CMFActivity: drop DTML completely and use consecutive uids when possible · d64887cb
      Julien Muchembled authored
      This moves the remaining DTML queries to Python, dropping the 'activity' skin.
      
      Dealing with conflicts of uids is easier if the inserted uids are consecutive:
      now, only 1 random value is generated, as base uid. This also preserves the
      order of insertion, which is wanted for performance reasons:
      - No more random write in the primary index.
      - When modifying several lines of several documents, 1 document being processed
        at a time, we'd like that any grouped activity (usually indexation) follows
        the same order, so that a processing node prefer many lines from a few
        documents instead of mixing lines from too many documents at the same time.
        This is usually better for caches.
      d64887cb