1. 08 Jun, 2020 9 commits
  2. 05 Jun, 2020 8 commits
  3. 04 Jun, 2020 1 commit
  4. 03 Jun, 2020 10 commits
  5. 02 Jun, 2020 5 commits
  6. 01 Jun, 2020 7 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
    • Jérome Perrin's avatar
      erp5_core_test: style fixes · a87da503
      Jérome Perrin authored
      a87da503
    • Jérome Perrin's avatar
      74693110
    • Jérome Perrin's avatar
      monaco_editor: don't use automaticLayout for now · 1bdcae33
      Jérome Perrin authored
      In monaco 0.20.0 "peek references" is not properly displayed when
      automaticLayout is true. This is fixed on master branch so next release
      should be OK.
      
      For now, use a resize event handler to re-layout the editor when size
      change, then we don't need the automaticLayout.
      1bdcae33
    • Jérome Perrin's avatar
      monaco_editor: put body before head · 6b8e263b
      Jérome Perrin authored
      document.body is accessed very early in scripts loading, in
      https://github.com/microsoft/vscode/blob/c6e3a94892eaccbce9995ee02a06febec5492fec/src/vs/editor/contrib/suggest/suggestRangeHighlighter.ts#L106
      if we leave body after head, for some reason document.body is null here
      and loading fail, which leaves an editor where things like Ctrl+Space
      does not trigger completions
      
      Moving body before head is just a workaround, but that was code was
      removed in
      https://github.com/microsoft/vscode/commit/f913854bd66362a1350ea43c305ad92c151796bf
      hopefully when we update to monaco > 0.20.0 that won't be needed again.
      6b8e263b