1. 15 May, 2023 2 commits
  2. 12 May, 2023 2 commits
  3. 08 May, 2023 2 commits
  4. 03 May, 2023 2 commits
  5. 02 May, 2023 7 commits
    • Jérome Perrin's avatar
      ProcessingNodeTestCase: also setRequest in processing_node · 18deb716
      Jérome Perrin authored
      This is done on the process running test (by
      ERP5TypeTestCaseRequestConnection) and when using timerserver loop (by
      TimerServer which calls publish_module), but this was never set in
      processing_node.
      
      Before 3b874e49 (ERP5Type/tests: review requests in tests, 2023-04-19)
      getRequest could find a request anyway, because the test pached
      getRequest to find a request from the app, but after this change
      executing activities in an instance running with runUnitTest without
      test specified failed with:
      
          Module importlib, line 37, in import_module
            __import__(name)
          Module Products.ERP5Type.dynamic.component_package, line 412, in load_module
            return self.__load_module(fullname)
          Module Products.ERP5Type.dynamic.component_package, line 379, in __load_module
            erp5.component.ref_manager.add_module(module)
          Module Products.ERP5Type.dynamic.dynamic_module, line 75, in add_module
            self.add_request(get_request())
          Module Products.ERP5Type.dynamic.dynamic_module, line 53, in add_request
            self.setdefault(last_sync, (WeakSet(), set()))[0].add(request_obj)
          Module _weakrefset, line 86, in add
            self.data.add(ref(item, self._remove))
        TypeError: cannot create weak reference to 'NoneType' object
      
      ( maybe we remove processing_node and use only timerserver, these two
      methods are more or less equivalent for simple cases and timerserver is
      closer to what a "real" zope does )
      18deb716
    • Xiaowu Zhang's avatar
      a6f74a19
    • Jérome Perrin's avatar
      tests: execute `addCleanup` cleanups with ZODB connection · 25eb8920
      Jérome Perrin authored
      unittest executes the cleanups after `tearDown`, after the ZODB
      connection is closed, so accessing database objects cause errors.
      
      According to python unittest documentation, it is safe to call
      `doCleanups` ourselves when we need the cleanup to be executed earlier,
      this is a typical case where we want the cleanup to be called before
      closing the database connections.
      25eb8920
    • Jérome Perrin's avatar
      core: "better" default columns in Base_viewRelatedObjectListBase · 4350a316
      Jérome Perrin authored
      ID is not something we like to show to users, modification date and
      validation state can be better - this assumes that most of the
      relation are made to nodes, which typically have a validation state
      and not a simulation state.
      4350a316
    • Jérome Perrin's avatar
      ERP5Type/tests: review requests in tests · 3b874e49
      Jérome Perrin authored
      The general idea of this patch is that now that we are using
      zope.globalrequest, we no longer need to patch get_request, we can
      simply call zope.globalrequest.setRequest with the request from the
      test and restore the "real" request afterwards.
      
      To achieve this, we reuse Testing.ZopeTestCase.connections.registry,
      which already has the logic of cleaning up resources in the right place
      and use a "Request" resource that calls setRequest(test_request) and
      setRequest(real_request) when closed, so that:
       - test runs with an independant request
       - this test request is closed at the end
       - the real request is restored at the end
      
      This also fixes a bug with self.publish when runnning
      ERP5TypeLiveTestCase from portal_components of a running instance,
      after a call to self.publish the current request was lost.
      
      The testing for this revealed that ERP5TypeLiveTestCase.publish way
      of dealing with zope.security interaction was not always correct: when
      running a live test inside runUnitTest (like we do here in
      testDynamicClassGeneration), there is no security interaction. This
      was reviewed to use the high level API instead of changing directly the
      internal storage.
      3b874e49
    • Jérome Perrin's avatar
      core: expose `is_source` on `MovementHistoryListBrain` · e1ae4c69
      Jérome Perrin authored
      This can be useful when making a report on movements and when we list
      properties of the movements that depend on the side but are not
      directly exposed on MovementHistoryListBrain. One use case was
      `Movement_getSpecificReference`, which shows `source_reference` when
      the brain is for the source and `destination_reference` otherwise.
      
      With this new approach, instead of guessing we record the "is_source"
      information at indexing time, when we know this for sure.
      
      This also simplifies `MovementHistoryListBrain.date` and
      `MovementHistoryListBrain.mirror_date` which no longer need to guess
      the side and fix a problem that because this guessing was done using
      `movement.getSourceUid()` - which cause security errors when users can
      not access the source of the movement.
      e1ae4c69
    • Jérome Perrin's avatar
      worklfow: save state permissions sorted · f4cd9eb2
      Jérome Perrin authored
      When editing a state permission mapping the roles were not sorted,
      because WorkflowState_getPermissionMatrixContext uses a set. Sort
      before setting the attribute, to prevent useless diffs in ZODB history
      and business template.
      f4cd9eb2
  6. 27 Apr, 2023 2 commits
  7. 26 Apr, 2023 2 commits
  8. 25 Apr, 2023 1 commit
  9. 21 Apr, 2023 2 commits
    • Nicolas Wavrant's avatar
      erp5_core: fix addToDate when removing a month · c1dfe5d8
      Nicolas Wavrant authored
      See merge request !1768
      c1dfe5d8
    • Nicolas Wavrant's avatar
      erp5_core: fix addToDate when removing a month · 34d26a74
      Nicolas Wavrant authored
      The way addToDate was working with dates was not good, and creating
      confusion when removing 1 month from the last days of a 31-day month, as
      the previous day had less days than the current month:
      
      date = DateTime(2023, 5, 31)
      print date
      print addToDate(date, month=-1)
      > 2023/05/31 00:00:00 GMT+2
      > 2023/05/01 00:00:00 GMT+2
      
      This was even more confusing in March, with february having only 28
      days:
      
      date = DateTime(2023, 3, 31)
      print date
      print addToDate(date, month=-1)
      > 2023/03/31 00:00:00 GMT+2
      > 2023/03/03 00:00:00 GMT+2
      
      The new behavior is to, when removing a month, if the new day of the new
      month is more than the number of days in month to default to the last
      day of the month. For exemple, removing one month from 31/05 becomes
      30/04, and from there it will add/remove the days as necessary.
      
      The real issue being that removing a month is ambiguous and can mean
      a different thing for different people.
      
      For reference, the reference implementation of timedelta in python
      doesn't support adding months:
      
      https://docs.python.org/3/library/datetime.html#datetime.timedelta
      
      I hope my solution will make the more sense in ERP5's context.
      34d26a74
  10. 20 Apr, 2023 1 commit
  11. 17 Apr, 2023 1 commit
  12. 12 Apr, 2023 1 commit
  13. 11 Apr, 2023 1 commit
  14. 10 Apr, 2023 2 commits
  15. 07 Apr, 2023 1 commit
    • Jérome Perrin's avatar
      open_api: new business template · 36948198
      Jérome Perrin authored
      This is a simple framework to implement services in ERP5 based on an
      OpenAPI document.
      
      A new type "Open API Type" (similar to "Base Type") is introduced,
      this is responsible for the definition of operations and types.
      The Open API document is set as text content of the Open API Type
      and can be edited from the Open API Type.
      
      For each service, a new portal type will be created. The portal type
      use OpenAPIService as class and this is responsible for serving
      requests. The process of serving requests is:
       - find the matching operation from the request method and request
         path
       - extracting request parameters and request body using the parameter
         definitions from the Open API Document
       - validate parameters and request body according to the schema from
         the Open API document
       - finding the method, this is done by using _getTypeBasedMethod with
         the operationId
       - calling the method and formatting the result or handling error.
         The default handling of errors is to reply with rfc7807 json
         responses, but it can be customized by defining an
         `handleException` type based method.
      
      Typically, the services will be created in portal_web_services. From
      there, there is also a view using a new SwaggerUI gadget to try out
      the API.
      
      What's not supported:
       - OpenAPI document in YAML format is only partially supported and
         have some limitations over JSON:
          - On python2 the order of operations is lost, the lookup of
            operations is not made in the order of the operations from the
            document. Also the operations are not in order in the SwaggerUI
            gadget.
          - The text editor does not provide rich editing of YAML
       - "partial" parameters in path elements ( /users/{user_id} is
         supported, but /documents/report.{format} is not )
       - XML (decoding of request bodies and parsing of responses) is not
         supported.
      36948198
  16. 06 Apr, 2023 2 commits
  17. 05 Apr, 2023 4 commits
  18. 03 Apr, 2023 5 commits