1. 19 Feb, 2021 1 commit
  2. 16 Feb, 2021 1 commit
  3. 15 Jan, 2021 3 commits
  4. 13 Jan, 2021 1 commit
  5. 09 Dec, 2020 1 commit
  6. 01 Dec, 2020 1 commit
  7. 27 Nov, 2019 3 commits
  8. 26 Nov, 2019 1 commit
    • Jérémy Bobbio (Lunar)'s avatar
      Update Debian packaging with support for Python 3 · f2afca59ed1b
      Jérémy Bobbio (Lunar) authored
      The new binary package with Python 3 support is named
      python3-cubicweb-jsonschema according to current standards.
      Python 2 package is also updated to use the proper namespace
      and a transitional package has been introduced to handle
      the migration.
      We also take this opportunity to run the tests at build time.
      Support for Python 3.8 is disabled as it is currently broken
      in Debian unstable.
  9. 07 Mar, 2019 2 commits
  10. 13 Dec, 2018 4 commits
  11. 31 Oct, 2018 1 commit
  12. 06 Jul, 2018 1 commit
    • Denis Laxalde's avatar
      Detect bad mime types upon data submission views · d2b673a15823
      Denis Laxalde authored
      Previously, we did "request.json_body" in every data submission views
      (like entity creation or update, with HTTP method being POST or PUT).
      This instruction might fail with JSONDecodeError exception if the body
      fails to JSON decode. This would result in a 500 error response. Rather
      we want to return a 40x response indicating that this is a client error.
      So we now raise a 415 Unsupported Media Type error through a
      _json_body() helper function every times we need to decode JSON body of
      incoming requests. Notice that since json module only has
      JSONDecodeError exception on Python3+, we catch ValueError on Python2.
      A functional test is added for entity creation view.
  13. 26 Jun, 2018 3 commits
  14. 19 Jun, 2018 1 commit
    • Denis Laxalde's avatar
      Use resource interfaces for context of API views · fe8187f8d252
      Denis Laxalde authored
      We define interfaces (using zope.interface) for main resource classes
      and refer to these interfaces (as dotted names) in API views' context
      instead of registering these views against the resource classes
      The idea is to make it possible for downstream applications to register
      their own resource classes that could be selected by standard API views.
      Interfaces have attributes and methods declared based on what appears to
      be needed on API views. We use interface inheritance to reduce
      duplication (e.g. the IMapped interface is a base for all interface but
      IRoot; IRelatedEntities is a base for IRelatedEntity).
      Notice that this somehow conflicts with the Mappable abstract class that
      was defined previously in resources module; so we drop this abstract
      class and replace it by an IMapped interface.
  15. 20 Jun, 2018 1 commit
    • Denis Laxalde's avatar
      Move permission check logic from get_entities() view to the resource · 52dcc1f1a143
      Denis Laxalde authored
      Instead of assuming that the context resource in get_entities() view has
      an "etype" attribute (which won't be true anymore in next changeset), we
      delegate permission check to the resource object in the form of an
      has_perm() method. This is step towards defining abstract interfaces for
      resource classes.
  16. 19 Jun, 2018 2 commits
    • Denis Laxalde's avatar
      Implement attributes of Paginable resource as properties · 62934d2097ac
      Denis Laxalde authored
      I'm getting into trouble while trying to reuse this class in a multiple
      inheritance context because the proper __init__ method is never called.
      So, let's get rid of __init__ in Paginable and implement 'limit',
      'offset' and '_has_next' attributes, previously defined in __init__ as
      reified properties. Notice that, since _has_next may be changed (in
      paginate() method), we also need a setter for this property.
      Accordingly, drop super() calls in resource classes inheriting from
      Paginable and mention that this class should be used as a mixin.
    • Denis Laxalde's avatar
      Add a CollectionMapper for unspecified entity types · 62523c338920
      Denis Laxalde authored
      This is useful for representing collection of heterogeneous entities.
      This mapper would be selected by its regid only, with no extra argument
      in contrast with other 'jsonschema.collection' mappers that either
      accepts an "etype" parameter or a relation context. This mapper does not
      handle submission (i.e. entity creation) since the target entity type is
      unspecified; so we return a "false" JSON Schema for "creation" role.
      In tests, we rename prior test case CollectionMapperTC as
      EntityCollectionMapperTC and add back a CollectionMapperTC explicitly
      testing the new mapper class.
  17. 02 May, 2018 1 commit
  18. 17 Apr, 2018 1 commit
  19. 11 Apr, 2018 1 commit
  20. 09 Apr, 2018 2 commits
  21. 05 Apr, 2018 1 commit
  22. 30 Mar, 2018 4 commits
  23. 27 Mar, 2018 1 commit
    • Denis Laxalde's avatar
      Add a dedicated error view for cubicweb's RequestError · 1db2dd27c01e
      Denis Laxalde authored
      This view will be selected upon any exception which is a subclass of
      cubicweb.web.RequestError when the request has Accept:application/json.
      Previously, the "generic_error" view would have been called, but it
      cannot accurately handle CubicWeb's web exceptions (it always returns
      500, whereas these web exceptions may have a different status code).
      Why are these views selected? This is because the RootResource matches
      for any request with this Accept:application/json header. (In fact, we'd
      want to use this error view only when the request comes from a
      sub-resource of the RootResource; but that's not easy to achieve.)
      So this new error view convert a cubicweb.web.RequestError into an
      application/problem+json response. This is thus not backward compatible
      with what CubicWeb would return.
      In added test, we use the "format_date" "ajax" controller (of CubicWeb)
      with missing argument which then responds with a RemoteCallFailed (with
      a 500 status) that is called by our view.
  24. 20 Mar, 2018 1 commit
    • Denis Laxalde's avatar
      Let yams_match respect Predicate.__call__ interface · ee7941762504
      Denis Laxalde authored
      CubicWeb's Predicate's __call__ method's interface is:
        def __call__(self, cls, req, **kwargs):
      In yams_match, we had 'rtype' and 'role' as non-keyword arguments, thus
      producing TypeError upon calls of a class's __select__ without all
      required arguments. We change this to have 'rtype' and 'role' option
      (though score will still be 0 if they are unspecified) so that we now
      respect base interface.
  25. 19 Mar, 2018 1 commit