1. 03 Jul, 2017 3 commits
    • Jérome Perrin's avatar
      tests: we no longer run namingConventionTest.py · ae59d7cd
      Jérome Perrin authored
      We have testERP5NamingConvention.py for this purpose.
      ae59d7cd
    • Jérome Perrin's avatar
      CodingStyle: `Zuite` is a valid prefix · a7e02fda
      Jérome Perrin authored
      a7e02fda
    • Jérome Perrin's avatar
      More pylint integration · fbeff3f4
      Jérome Perrin authored
      Since early days of @arnau work on ERP5 components, we have pylint integrated as a way to check the code in components and in python scripts but nothing prevents us from commiting code with lint errors, leaving the problem for the next developer. 
      
      For this, I extended [`CodingStyleTestCase`](https://lab.nexedi.com/nexedi/erp5/blob/88e4b34ff67aa07447f81c8af836feba607843e8/product/ERP5Type/tests/CodingStyleTestCase.py) that was introduced for very similar purpose so that it also  use our tool to check python code. This way,  we can have failing tests when the code do not pass pylint.
      
      What's still not good is that if we want a business template to be tested, we have to explicitly add a test for this business template, but it's also the case for all our "static" tests (naming conventions, HTML validation etc).
      
      
      A missing feature was that there was no way to get an overview of all the reported problems on a business template. For this, I added a report action on business template that uses the same code to display errors in all *python* code from a business template:
      
      ![ERP5_pylint_business_template](/uploads/13613199227884f0340b8f1c40ca4418/ERP5_pylint_business_template.png)
      ( the lines have direct links to edit python code )
      
      Because `testERP5WebCodingStyle` was already here checking `erp5_web` (well not really because it was no longer using `CodingStyleTestCase` correctly) , I fixed all problems reported by pylint in erp5_web. In reality it only took a few minutes to do this.
      
      PS: I don't know exactly how we could integrate javascript linter in all this. We have a [`test_javascript_lint`](https://lab.nexedi.com/nexedi/erp5/blob/master/product/ERP5/tests/testXHTML.py#L171), but it does not test much of the code written recently because it only checks portal skins. @romain and @vincentB maybe have plans for this. Anyway, it's out of the scope of this.
      
      /cc @kazuhiko @vpelletier @tc 
      
      /reviewed-on nexedi/erp5!308
      fbeff3f4
  2. 30 Jun, 2017 1 commit
  3. 29 Jun, 2017 13 commits
  4. 28 Jun, 2017 18 commits
  5. 26 Jun, 2017 3 commits
    • Jérome Perrin's avatar
      accounting: review AccountModule_getAvailableGapList · 7859a03f
      Jérome Perrin authored
      * Remove include_empty_item: We always want an empty item in dialogs
      * Remove include_gap_in_path: This was always true
      
      simplify code a little bit.
      7859a03f
    • Jérome Perrin's avatar
      fixup! accounting: translate GAP category in account view · d1bd710e
      Jérome Perrin authored
      * There was another level of cache in Account_hashGapItemList
      * Category title was used in AccountModule_getAvailableGapList
      d1bd710e
    • Vincent Pelletier's avatar
      MemcachedTool: Pool memcache.Client instances · d9c996fd
      Vincent Pelletier authored
      Unlike other database adaptors, memcache adaptors can be shared among
      transactions. So pool them in order to reduce the number of connections
      established to memcached servers. And as the connections handle
      thread-safety internally (by inheriting from threading.local), threads
      can share the same connection instance.
      Also, do not create a new connector each time we get disconnected, just
      reconnect.
      Also, memcached internally retries connection, so no need to retry it
      ourselves.
      Also, do not log when failing to update & delete entries in cache
      server: this is a racy cache, each read much be checked anyway, so
      failed writes are just business as usual.
      Also, document a bit more why we catch "any" exception happening during
      finish, and specify base exception class following python coding best
      practices.
      Also, use named constant for loggin levels for remaining log directives.
      Also, display traceback when catching a connection issue during
      __getitem__, as the original exception gets converted into a KeyError.
      d9c996fd
  6. 23 Jun, 2017 2 commits