1. 08 Aug, 2016 4 commits
  2. 05 Aug, 2016 5 commits
  3. 04 Aug, 2016 5 commits
  4. 03 Aug, 2016 1 commit
  5. 02 Aug, 2016 3 commits
    • Ayush Tiwari's avatar
      erp5_standard_property: Add select_variable property for Standard Property object. · 3cf4d7f7
      Ayush Tiwari authored
      This change solves the error which one gets while trying to access properties
      Form for an ERP5 object having one or more of its property of type 'selection'
      or 'multiple selection'.
      For example: If you try to access property form for any portal_type objects,
      you'll get an error : "'select_variable' is not defined". This is because of the
      absence of the property 'select_variable' for the property of type multiple selection,
      which in case of portal_type object is 'Property Sheet List'.
      This is helpful for ERP5 views/forms which displays selection or multiple selection
      type object.
    • Ayush Tiwari's avatar
    • Ayush Tiwari's avatar
      ERP5 Subcategory: Remove '_'(underscore) from 'multiple_selection' subcategory... · 1075a315
      Ayush Tiwari authored
      ERP5 Subcategory: Remove '_'(underscore) from 'multiple_selection' subcategory in elmentary_type category.
      Subcategory 'multiple_selection' has been renamed to 'multiple selection' to maintain consistency.
      Earlier, whenever a new StandardCategory object was created with property_type 'multiple selection',
      one needed to change the elementary type explicilty to use it to generate property setters and getters.
      The example for this can be seen from this commit:
      After this change, in the view, property type field couldn't recognize the property and displays
      (???multiple selection).
      Also, everywhere in erp5, list_types do mention 'multiple selction' and not 'multiple_selection'.
      So, its better to maintain consistency in naming the subcategory.
  6. 01 Aug, 2016 1 commit
  7. 29 Jul, 2016 6 commits
  8. 28 Jul, 2016 2 commits
  9. 27 Jul, 2016 1 commit
  10. 25 Jul, 2016 2 commits
  11. 21 Jul, 2016 2 commits
  12. 19 Jul, 2016 3 commits
  13. 16 Jul, 2016 1 commit
    • Julien Muchembled's avatar
      HBTreeFolder2 fixes · c3450f14
      Julien Muchembled authored
      There's no magic in this patch series: it is known that HBTreeFolder2 has
      limitations about the ids that can be set without conflict, and this can't be
      fixed without causing compatibility issues with existing data.
      The patches contain:
      - some optimization
      - bug fixes
      - detection of id conflicts before causing data loss
      This will also allow us to use a newer version of ZODB. Recent BTrees failed
      on the following line of `_setOb`:
              if len(id_list) == 1 and not htree.has_key(None):
      (None is not valid key for comparison since
       ZODB commit bb5aac21277f43333d6450064dc6670c8c280e40)
      The long story about id conflicts is that a HBTreeFolder2 can't store 2 objects
      <A> and <A>-<B> where <A> does not contain '-', and that's the rule followed by
      _getOb/_setOb/_delOb. However:
      - Conflicts are detected by testing the type of the value, which means
        HBTreeFolder2 can't store values of the same type as the one it uses
        internally (i.e. OOBTree).
      - For performance reasons, _htree_iteritems and getTreeIdList use a stricter
        rule: they assume there can't be 2 objects <A> and <A>-<B>, regardless of the
        presence of a separator in <A>. Maybe this rule should be enforced in _setOb.
      /reviewed-on !112
  14. 15 Jul, 2016 4 commits