1. 09 Jun, 2020 9 commits
  2. 08 Jun, 2020 2 commits
  3. 05 Jun, 2020 10 commits
  4. 04 Jun, 2020 1 commit
  5. 03 Jun, 2020 10 commits
  6. 02 Jun, 2020 5 commits
  7. 01 Jun, 2020 3 commits
    • Jérome Perrin's avatar
      TrashTool: fail if backup object container already exist · e86c6071
      Jérome Perrin authored
      This is not supposed to happen and can hide errors.
      e86c6071
    • Jérome Perrin's avatar
      BusinessTemplate: fix simulataneous update of categories and paths · 43adfa98
      Jérome Perrin authored
      This addresses the problem of
      https://nexedijs.erp5.net/#/bug_module/20180719-135FAA8 a KeyError
      raised when some categories in a subtree are modified and some are
      removed and the corresponding base category is also installed as a base
      category.
      
      The problem was that both CategoryTemplateItem, which is in charge of
      updating the base category and PathTemplateItem, which is in charge of
      updating the categories listed as path both use the same
      ObjectTemplateItem.install method, with the same object_to_update dict.
      ObjectTemplateItem.install uninstall all objects that are listed in
      object_to_update and not in self._objects so something like this
      happened when business template from
      test_update_business_template_with_category_having_subcategory_tree_modified
      is updated:
      
        1. PathTemplateItem.install is called for the base category,
      portal_categories/test_category/modified/removed looks removed, so it is
      backed up. Because the the parent paths are not parts of self._objects,
      trash tool will create simple trash folder for
      portal_categories/test_category/modified
      
        2. PathTemplateItem.install is called for the paths,
      portal_categories/test_category/modified is modified, so the previous
      version will be backed up. At this point trash tool looks in the trash
      bin and the path for portal_categories/test_category is already present,
      so trash tool sees that path exists and does not return subobjects, so
      after portal_categories/test_category/modified is modified, the subjects
      such as
      portal_categories/test_category/modified/container_in_which_child_is_added
      are not restored and creating 'added' caused a
      KeyError('container_in_which_child_is_added')
      
      The approach is to make CategoryTemplateItem.install only consider base
      categories - ie. objects where path is portal_categories/* and not the
      subobjects, because they don't belong to CategoryTemplateItem but to
      PathTemplateItem.
      Co-authored-by: Georgios Dagkakis's avatarGeorgios Dagkakis <georgios.dagkakis@nexedi.com>
      43adfa98
    • Jérome Perrin's avatar
      BusinessTemplate: tolerate broken objects when updating their containers · 31f8dfe2
      Jérome Perrin authored
      Business template have some logic to keep uids when updating objects:
      during installation, when an object is modified, business template first
      remember the uids for this object and all its sub-objects,
      replaces this object with the new version then recursively set the uid
      on updated objects, so that updating an ERP5 document by business
      template does not change its uid because this would break catalog.
      
      When an object containing sub-objects is updated, it becomes a new
      object in ZODB and sub-objects of the previous object are set as child
      of the new object. This works even if the case of sub-objects being
      instances of ZODB Broken class, except that the step where we restore
      the uid fail as it's not allowed to modify a broken object.
      
      Instead of unconditionnally setting the sub-objects uids, check that we
      actually need to set it, because if it's already the expected value then
      we don't need to touch the object.
      31f8dfe2