An error occurred fetching the project authors.
  1. 19 Feb, 2014 1 commit
  2. 16 Jan, 2014 3 commits
  3. 04 Jan, 2014 1 commit
  4. 05 Nov, 2013 1 commit
  5. 30 Oct, 2013 1 commit
  6. 25 Oct, 2013 2 commits
  7. 07 Oct, 2013 3 commits
  8. 11 Sep, 2013 1 commit
  9. 10 Sep, 2013 4 commits
  10. 09 Sep, 2013 2 commits
    • Arnaud Fontaine's avatar
      ZODB Components: Fix bootstrap of migrated bt5s. · aed4f303
      Arnaud Fontaine authored
      * Upon bt5 installation, install portal_type* items before bt5 {Document,
        Extensions...} as corresponding Portal Type are required once they have been
        migrated to ZODB Components.
      
      * Likewise portal_{property_sheets, types}, portal_components must be created
        automatically *before* installing any bt5. This is required when Products
        will be migrated but also for bt5 items before bootstrapping erp5_core bt5.
      
      * Set Permissions in ComponentTool instanciation and revoke all permissions,
        then allow only some of them for security sake.
      
      * When creating ERP5 site with unit tests, add ERP5TypeTestCase to Developer
        Role ASAP so that there is no Permission issue when installing bootstrap bt5
        and test bt5s containing ZODB Components.
      aed4f303
    • Arnaud Fontaine's avatar
      ZODB Components: Upon migration, Workflow History of ZODB Components must be kept. · dce6323f
      Arnaud Fontaine authored
      Also, upon installation of bt5s, install WorkflowItem before Components as it
      is needed to restore history.
      
      Another solution would have been to validate() ZODB Components automatically
      upon bt5 installation but it would mean losing 'modified' state information
      and also imply that *all of them* will be validated even if a developer wants
      to publish non-validated ZODB Components.
      dce6323f
  11. 19 Aug, 2013 2 commits
  12. 01 Jul, 2013 1 commit
  13. 21 Jun, 2013 2 commits
  14. 10 Jun, 2013 1 commit
  15. 05 Jun, 2013 1 commit
    • Arnaud Fontaine's avatar
      Avoid regeneration of classes when starting a node within a cluster with already started nodes. · 20362ede
      Arnaud Fontaine authored
      When starting a node, ERP5Site.__of__ calls ComponentTool.reset(), which was
      never synchronised so it returned True (without generating a new cookie at its
      level) and causing synchronizeDynamicModules to be called with
      force=True. This generated a new cookie and leading to dynamic classes being
      meaninglessly regenerated on all nodes.
      
      Instead, modify ComponentTool.reset() behavior so it *always* reset Portal
      Type classes when Components are reset (as it should have always been as the
      class inheritance may have been modified) and force regeneration of Portal
      Type classes in this method if reset is True.
      Signed-off-by: Vincent Pelletier's avatarVincent Pelletier <vincent@nexedi.com>
      20362ede
  16. 21 May, 2013 1 commit
  17. 12 Apr, 2013 1 commit
  18. 04 Apr, 2013 1 commit
  19. 25 Jan, 2013 1 commit
  20. 07 Dec, 2012 1 commit
  21. 08 Nov, 2012 1 commit
  22. 05 Nov, 2012 1 commit
  23. 08 Oct, 2012 1 commit
  24. 13 Sep, 2012 1 commit
  25. 16 Aug, 2012 2 commits
  26. 12 Jul, 2012 1 commit
  27. 02 Jul, 2012 1 commit
  28. 27 Jun, 2012 1 commit