1. 18 Oct, 2019 1 commit
  2. 17 Oct, 2019 2 commits
    • Arnaud Fontaine's avatar
      ZODB Components: Add 'Origin' (source_reference) field showing from which FS... · cf632afb
      Arnaud Fontaine authored
      ZODB Components: Add 'Origin' (source_reference) field showing from which FS module it was imported.
      cf632afb
    • Arnaud Fontaine's avatar
      ZODB Components: Do not validate nor check {consistency,source code} after importing from FS. · 799da311
      Arnaud Fontaine authored
      * pylint may return a false positive error which have to be disabled and
        failing to import it because of that requires to edit on the FS and try
        again so it is not practical for a whole Product. Instead it is easier
        to import it and not validate
      * Validation was done only for 'Test Component' and 'Extension Component',
        but all imported Components had their consistency and source code checked
        and this is not consistent to not validate but do these checks.
      * importFromFilesystem() was checking consistency and source code, and this
        was done again when validating.
      
      So leave the imported ZODB Components as draft and let the developer fixes
      issues upon validation before committing.
      799da311
  3. 16 Oct, 2019 1 commit
    • Arnaud Fontaine's avatar
      ZODB Components: List of migratable 'Module Components' in Products.XXX.*... · f675c0fb
      Arnaud Fontaine authored
      ZODB Components: List of migratable 'Module Components' in Products.XXX.* should include any kind of objects and not only modules.
      
      This fixes Products.ERP5VCS.Git module not being displayed because
      Products.ERP5VCS.__init__ only imports one of its class and not the whole
      module (and the module was not imported anywhere else too) so it was not in
      Products.ERP5VCS.__dict__.
      f675c0fb
  4. 15 Oct, 2019 2 commits
  5. 14 Oct, 2019 1 commit
  6. 11 Oct, 2019 2 commits
  7. 10 Oct, 2019 7 commits
  8. 09 Oct, 2019 7 commits
  9. 08 Oct, 2019 4 commits
  10. 07 Oct, 2019 7 commits
  11. 05 Oct, 2019 3 commits
  12. 04 Oct, 2019 3 commits
    • Julien Muchembled's avatar
      Optimize WorkflowHistoryList · 1ca655a3
      Julien Muchembled authored
      This is done by inheriting most of the code of ConflictFreeLog,
      i.e. using a doubly-linked list:
      - for fast iteration of the first elements, and in particular
        immediate access to the first element (used for creation date);
      - that keeps track of the history length;
      - that implement fast reverse iteration (although it could
        have been done without changing the data structure).
      
      The size of buckets is not fixed anymore to 16 items:
      like ConflictFreeLog, WorkflowHistoryList is also a good candidate
      to look at the estimated serialized size of the bucket in order to
      decide if elements should be added to a new one or not.
      Then developers won't have to care about using Pdata or not.
      
      The size is bigger than the ConflictFreeLog default,
      because workflow items look a lot alike and adding
      a few more is cheap when the ZODB compresses.
      
      No more optimized __getstate__ (except for workflow histories that
      have not been migrated) so BT export will be a bit more verbose.
      
      The BBB code is because of
        nexedi/erp5!934
      
      /reviewed-on nexedi/erp5!941
      1ca655a3
    • Arnaud Fontaine's avatar
      ZODB Components: Before migrating Interfaces from FS, there must be one... · 694c9fee
      Arnaud Fontaine authored
      ZODB Components: Before migrating Interfaces from FS, there must be one Interface class per source file matching its name.
      
      Same as Document class: this avoids registering Interfaces at startup and just do it
      when using the Interface. In assuming that portal_components/XXX has a class
      name equals to XXX.getRference(), it is easier to:
       * List all existing Interfaces (for example in Portal Type Class view): getReference()
         on all validated 'Interface Component' in portal_components.
       * Lookup for an 'Interface Component': 'from erp5.component.interfaces.XXX import XXX'.
      694c9fee
    • Arnaud Fontaine's avatar
      ZODB Components: Properly handle addition of template_* properties in... · d9627917
      Arnaud Fontaine authored
      ZODB Components: Properly handle addition of template_* properties in BusinessTemplate PropertySheet.
      
      On the plus side, this avoids an ugly 'except AttributeError: pass' which does
      not work anyway with the scenario below.
      
      Assuming the following:
        * template_XXX Property (accessor: getTemplateXXX) recently added to BusinessTemplate PropertySheet.
        * erp5_YYY sets template_A Property (erp5_YYY/bt/template_XXX.xml).
        This commit handles the following:
          1. Stop instance with old ERP5 without template_XXX.
          2. Update erp5.git.
          3. Start instance.
          4. Upgrade erp5_property_sheets and erp5_YYY bt5s in *one* transaction from portal_templates UI.
          => When upgrading erp5_YYY, BusinessTemplate.importFile() imports erp5_YYY/bt/*.xml where the
             list of files is based on BusinessTemplate class propertyMap(), but at this point accessors
             have not been re-generated yet, thus template_XXX is not returned by propertyMap() and
             erp5_YYY/bt/template_XXX.xml is not imported.
             => portal_templates/erp5_YYY new BT does not have template_XXX property set at all.
      d9627917