1. 26 Nov, 2018 1 commit
  2. 15 Nov, 2018 1 commit
  3. 14 Nov, 2018 1 commit
  4. 12 Nov, 2018 2 commits
  5. 30 Oct, 2018 30 commits
  6. 29 Oct, 2018 2 commits
    • Arnaud Fontaine's avatar
      ZODB Components: Modules loaded by one Request were being GC'ed while executing in another Request. · f523edc4
      Arnaud Fontaine authored
      Until this commit, loading a ZODB Component would add it to the current Request
      object to prevent its reference counter reaching 0 (thus its global being reset to
      None and then being later GC'ed) when a reset happens in another Request.
      
      This problem was found when investigating testFunctionalConfigurator failure
      when installing bt5s as requested by the Configurator:
        1. Request R1 calls Zuite_waitForActivities importing extension.erp5.ERP5Zuite (M1).
           => Add M1 to R1._module_cache_set.
           => M1 ref counter equals to 2 (sys.modules and R1._module_cache_set references).
        2. R1 terminates and is GC'ed.
           => M1 ref counter equals to 1 (sys.modules).
        3. Request R2 runs Configurator configuring the Site.
        4. testFunctionalConfigurator calls Zuite_waitForActivities to wait for the
           Configurator to finish (request R3 which may take ~15 minutes). This calls
           time.sleep() in a loop where 'time' module is imported at top-level.
        5. R2 installs bt5 triggering reset.
           => M1 ref counter equals to 0.
              ===> M1 global variables are reset to None and thus 'time' is set to None
                   raising an Exception in the next call of time.sleep() in the loop.
      
      The easiest way would be to have a hook on sys.modules dict lookup and thus add M1
      to R2._module_cache_set when being imported, but this is not supported... Instead
      create a global cache on erp5.component package.
      f523edc4
    • Vincent Pelletier's avatar
      testTradeReports: Allow reusing in site-dependent security group setups. · fc3da930
      Vincent Pelletier authored
      This test alone does not define site-dependent security groups, so this
      change is not required as such.
      But in real configuration, ERP5 instance define security groups, which
      sometimes (often ?) depend on which site a document or user is linked to.
      When multiple groups apply (ex: having a certain function at a certain
      site), the final group is composed by joining group identifiers using
      underscores. This forbids using underscores in group identifiers.
      And group identifiers are generated from document's (here, the Category)
      codification if set, otherwise the reference if set, otherwise the document
      identifier.
      So set a underscore-less codification on these categories so this test can
      be run on tests where security is configured to include site in security
      groups.
      fc3da930
  7. 26 Oct, 2018 2 commits
  8. 25 Oct, 2018 1 commit