1. 04 Sep, 2014 1 commit
  2. 30 Jan, 2014 1 commit
  3. 27 Nov, 2013 1 commit
  4. 21 Jun, 2013 1 commit
  5. 31 Mar, 2011 2 commits
  6. 24 Mar, 2011 2 commits
  7. 16 Mar, 2011 1 commit
  8. 04 Feb, 2011 1 commit
  9. 07 Jan, 2011 1 commit
  10. 06 Jan, 2011 2 commits
  11. 22 Dec, 2010 1 commit
    • Nicolas Dumazet's avatar
      First step of migration to zodb property sheets · 9ddcbfc1
      Nicolas Dumazet authored
      * ERP5Type.PropertySheet becomes a dynamic module that returns strings
        instead of classes for compatibility:
        - the document classes can now use strings in property_sheets attribute
        - if a document uses a string instead of a class reference to point to a
          property sheet, it means that the property sheet can either be an old
          (filesytem, local, in a product) property sheet, or a zodb propertysheet
      
        For now, the contents of ERP5Type.PropertySheet (strings) are overwritten
        if a local PropertySheet is loaded from the disk. But with time, as
        property sheets will migrate to ZODB, the module will empty itself and
        contain only strings.
      
      * Move all property sheets from all products to ERP5PropertySheetLegacy
        product. Only property sheets that were left 'as is' are CMF* property
        sheets.
      
      This commit is mostly a move to another Product, and should have small
      consequences on tests/existing instances.
      
      However, if you used to import PropertySheets in custom/project code
      in your custom Property Sheets, you will need to rename:
         from Products.*.PropertySheet.Foo import Foo
      to:
         from Products.ERP5PropertySheetLegacy.Foo import Foo
      
      
      
      git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@41639 20353a03-c40f-0410-a6d1-a30d3c3de9de
      9ddcbfc1
  12. 15 Oct, 2010 1 commit