1. 18 Nov, 2019 1 commit
  2. 14 Nov, 2019 2 commits
  3. 31 Oct, 2019 2 commits
  4. 30 Oct, 2019 2 commits
  5. 29 Oct, 2019 2 commits
    • ZODB Components: Enable checking of imports with pylint. · 1cb2dc4c
      Until now it was disabled which means that if Component A imports Component B
      and the latter is not in {validated,modified} state, Component A could be
      validated without raising any error and failed at execution time.
      
      As this relies on Pylint transform/hook and avoiding monkey patch as much
      as possible, make Products.ERP5Type.patches.pylint available for Python3 (not
      actually tested with ERP5 but no AttributeError nor ImportError with Python3
      with this code).
      
      Also, allow developer to call validate action from 'modified' state to handle
      import use case:
        1. Edit A which raises an error stating that B.
        2. Fix B and validate it.
        3. Validate again A without requiring a modification of {reference,version,text_content}.
      Arnaud Fontaine committed
    • ZODB Components: Source code was checked even when setting text_content_{error,w… · 88a03532
      …arning}_message_list properties.
      
      So only check source code and validate when _set{TextContent,Reference,Version}
      are called and remove wildcards.
      Arnaud Fontaine committed
  6. 25 Oct, 2019 1 commit
  7. 23 Oct, 2019 1 commit
    • Introduce HTML to PDF Transform through Conversion Server (currently using wkhtmltopdf) (MR !955). · fb9a0d60
      Conversion Server code is no longer bound to OOo, as emphasized by:
        * Renaming of Preference Properties ooodoc_server* to document_conversion_server*.
        * Conversion Server exceptions are already defined in Document.py.
        * Conversion Server also handles video/audio/... conversions.
      
      Thus, refactor the code to connect to Conversion Server by moving it from
      Products.ERP5OOo.Document to Products.ERP5.Document.Document (while keeping
      backward compatibility):
        * Renamed:
          + OOoServerProxy => DocumentConversionServerProxy
          + OOO_SERVER_PROXY_TIMEOUT => DOCUMENT_CONVERSION_SERVER_PROXY_TIMEOUT
          + OOO_SERVER_RETRY => DOCUMENT_CONVERSION_SERVER_RETRY
        * Moved:
          + enc
          + dec
          + global_server_proxy_uri_failure_time
      
      Also, Introduced erp5.module.TransformLib (in erp5_core as currently all Transforms
      are there even though it should probably not be so) to define DocumentConversionServerTransform
      and which will hold libtransforms content when this will be moved to ZODB Components.
      
      Note: Ideally, OOOdCommandTransform should inherit from DocumentConversionServerTransform
      but wkhtmltopdf Handler on Cloudooo side is a hack only implemented in Manager.convertFile()
      whereas OOOdCommandTransform still uses legacy Manager.run_generate(), so leave it as it is
      to avoid breaking things (this will be addressed in a separate MR).
      
      /reviewed-on !955
      Arnaud Fontaine committed
  8. 17 Oct, 2019 2 commits
  9. 16 Oct, 2019 1 commit
  10. 11 Oct, 2019 1 commit
  11. 10 Oct, 2019 1 commit
  12. 09 Oct, 2019 1 commit
    • ZODB Components: Allow migration of {Interface,Mixin,Module,Tool} from Business … · d8961c51
      …Template UI and on all Products (not only Products.ERP5).
      
      This introduces the following new ZODB Components:
        + Module Component: Non-Documents/non-persistent classes of modules usually
          found at the top-level of Products (eg Products.ERP5.XXX) on FS. Considering
          that all other Components types are actually Modules, make it the base class.
        + Tool Component: Tool directory of Products on FS (eg Products.ERP5.Tool.XXX).
          => DiffTool and CallableTool are now 'Tool Component' instead of plain
             'Document Component' and properly registered as Tools like FS Products Tool.
      
      Skip CMFActivity and HBTreeFolder2 Products for now in migration View for now as
      almost many Portal Type classes have ActiveObject or HBTreeFolder2 in their MRO
      and these Products will be done at the end anyway...
      Arnaud Fontaine committed
  13. 08 Oct, 2019 1 commit
  14. 07 Oct, 2019 3 commits
  15. 04 Oct, 2019 4 commits
    • Optimize WorkflowHistoryList · 1ca655a3
      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
        !934
      
      /reviewed-on !941
      Julien Muchembled committed
    • ZODB Components: Before migrating Interfaces from FS, there must be one Interfac… · 694c9fee
      …e 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'.
      Arnaud Fontaine committed
    • ZODB Components: Properly handle addition of template_* properties in BusinessTe… · d9627917
      …mplate 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.
      Arnaud Fontaine committed
    • runUnitTest: 6f1c45c6 wrongly assumed that '--erp5_sql_connection_string' is always passed. · a3c40d0b
      This is the case with runUnitTest wrapper created by SlapOS but is not actually required
      as manage_addERP5Site has 'test test' as default value.
      
      This fixes:
        File "custom_zodb.py", line 70, in <module>
          sql_db = Products.ZMySQLDA.db.DB(os.environ['erp5_sql_connection_string'])
        File "UserDict.py", line 40, in __getitem__
          raise KeyError(key)
      KeyError: 'erp5_sql_connection_string'
      Arnaud Fontaine committed
  16. 02 Oct, 2019 7 commits
    • pdm: allow to acquire different description depending on supply lines · 3d96be34
      Exactly like prices and other properties, it is useful for some projects to define different
      descriptions depending if we are doing sales or purchases
      Sebastien Robin committed
    • [erp5_accounting/crm/project/trade] Activate actions for ERP5JS · 4f19f40f
      [erp5_core] Return 400 status code when updating a dialog
      Romain Courteaud committed
    • [erp5_xhtml_style] Support for fast input migration · 87884e2a
      Romain Courteaud committed
    • Verify parameters passed to category setters · 3978dba1
      This merge request aims to prevent programming errors by raising instead of silently doing nothing (which is a source of bugs).
      
      Currently, if an object as category property for a category "category", 2 families of setters were created :
      
      1. The string setter, following the format ```_setCategory``` and taking a relative URL as the argument.
      2. The value setter, following the format ```_setCategoryValue``` and taking an object as the argument.
      
      The issue is that developers may pass the wrong argument to one of these functions, having for consequences :
      
      1. For case (1), if an object is passed, the code would silently do nothing : nothing is set as relation, but the code doesn't fail. This is the worst case. 
      2. For the second case, passing a relative URL to ```_setCategoryValue``` would "work" (in the meaning the relation is set to the correct object). This may sound like a feature, but in my opinion it is confusing given the way ERP5 developers apprehend these setters nowadays.
      
      For case 1, a test is existing that an exception is raised, but due to coding error the feature disappeared and no one noticed : https://lab.nexedi.com/Nicolas/erp5/blob/b3ed2210ed6b30390b901c8620de6eafcc27a574/product/CMFCategory/tests/testCMFCategory.py#L810-815
      
      For case 2, compatibility code exists in the underlying function ```_setValue``` : https://lab.nexedi.com/Nicolas/erp5/blob/b3ed2210ed6b30390b901c8620de6eafcc27a574/product/ERP5Type/Base.py#L1840-1842
      
      In this MR, the exception caused by case (1) has been restored (so now it fails loudly).
      
      Case (2) has been deprecated, in order to keep backward compatibility.
      
      I have run the tests with the ```DeprecationWarning``` raising an error instead of just a warning,  and fixed the code were the setters weren't used correctly.
      
      Ideally, tests should always run with this ```DeprecationWarning``` being a real error so both cases crash loudly. This won't be part of this Merge Request.
      
      
      /reviewed-on !938
      Nicolas Wavrant committed
    • Connector to annotate commits with test results status on gitlab · b0972239
      This adds a new field on Test Suite Repository to configure a "gitlab connector".
      
      If this is set, then the commit from this repository will be annotated with the test status (failed or success). Gitlab uses these annotations to show that status on the merge request.
      
      At the same time, fix a few minor problems on `erp5_test_result`.
      
      /reviewed-on !924
      Jérome Perrin committed
    • Fix "incremental check" mode of consistency check alarm · 9a1cb966
      The way consistency check select documents to check at each run when running incremental mode, consistency seems to have issues which leads to documents not checked sometimes.
      
      I noticed two reasons:
      * When Zope runs with a timezone that is not `UTC`, the date comparison to find new documents compares a date in zope local timezone with a timestamp in mysql timezone. First fix is to pass a date to catalog, so that catalog convert it to the catalog timezone (it's a mistake to pass a date as string when using catalog programmatically). Second fix seem that we seem to need to configure mariadb to use `UTC` by default.
      * `alarm.getLastActiveProcess` does not return the latest active process when alarm is executing `activeSense` so we need to pass `include_active=True` in this case.
      
      /reviewed-on !537
      Jérome Perrin committed
    • Support properties' read permission in the GUI and in getProperty · 6c2435cf
      Because unlike `getFoo()`,  `getProperty('foo')` does not checks the permission defined on the accessor, when a form contain a `my_foo` field, the property would be displayed to the user who can view the form, even if the user does not actually have the permission to get this property. This because getter for default value of fields uses getProperty ( [here](https://lab.nexedi.com/nexedi/erp5/blob/58d4ab8efef748f522b3eaaecba3dc1133c99e72/product/ERP5Form/Form.py#L275) ).
      
      These changes modify behavior of `getProperty`, so that it enforces read permission security of properties and raise when user does not have permission to access properties.
      
      Some notes about implementation:
       * `getProperty` now becomes a bit slower, but it was incorrect before, so I guess it's inevitable.
       * some efforts have been made to keep the impact on performance minimal. This uses the same approach of  in `edit` of computing the set of restricted properties and using `guarded_getattr` only on these properties and using `getattr` on non-restricted properties. The computation of this set was moved  to dynamic class generation time and as a result, `edit` becomes a bit faster.
       * the `expectedFailure` part of `test_PropertySheetSecurityOnAccessors` was moved to another test, but I'm not even sure we want to support this (read-protecting properties with default write permission) as, to me, such configuration does not make much sense. 
       * new performance tests were added. I don't know what to use as min/max values so I just used something that should pass.
       * implementation for `getProperty('*_list')` was changed a lot, I have no idea why this was getting the method on the class and passing self as first argument. Now it we just get method on the instance, like we do for single properties.
      
      /reviewed-on !181
      Jérome Perrin committed
  17. 30 Sep, 2019 1 commit
  18. 26 Sep, 2019 2 commits
  19. 25 Sep, 2019 1 commit
    • ZEO tests: wait for other nodes to register · 0d996b48
      When other nodes takes time to start they are not always registered
      when the "main" node asserts that they are there.
      We observed problems in an environment where resolving localhost (by
      DNS) takes 10 seconds.
      
      Also introduce getOtherZopeNodeList utility method that can be useful in
      other ZEO tests in ProcessingNodeTestCase
      Jérome Perrin committed
  20. 24 Sep, 2019 1 commit
  21. 20 Sep, 2019 2 commits
  22. 18 Sep, 2019 1 commit