GitLab

And make the error message a bit more explicit.

Closes #17103219.

This is how yams_match predicate expects it.

When non-ASCII characters are present in "links" data, the previous
code (as it used bytes for string formatting) would try to encode this
data and may thus fail with a UnicodeEncodeError. To prevent this, we
use unicode string when formatting links parameters (i.e. add a u''
prefix). Nevertheless, we must still return a "native" string for
validity with WSGI specification (this is either bytes on Python 2 or
unicode string on Python 3):

  https://www.python.org/dev/peps/pep-3333/#a-note-on-string-types
  https://docs.pylonsproject.org/projects/webtest/en/latest/api.html#module-webtest.lint

Added regression tests accordingly.

Only RemoteCallFailed has an attribute called "reason", which is also the
message of the exception.

Use str() to have a compatible way to get the error message.

A JSON Schema must be a Boolean or an object.

For such values, we do not add the $schema property.

This renderer is defined in
cubicweb_jsonschema/api/schema.py:includeme().

Previously, we no transition was possible to fire, we would return an
empty array in the "oneOf" of "name" property, which is invalid (see
https://tools.ietf.org/html/draft-handrews-json-schema-validation-01#section-6.7.3).

So we return a "false" Boolean schema in these cases, thus clearly
indicating that no transition can be fired.

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.

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.

`etype_mapper` is not appropriate since the mapper bound to
ETypeResource is actually a "jsonschema.collection" mapper.

We introduce a assert_jsonschema_validate() helper function to reduce
code duplication.

Prior to introduction of CompositeRelationItemMapper in previous
changests, serialization of items of a composite relation that is not
inlined did not work. By making use of plain "jsonschema.item" mapper
for targets of such relations we make this possible.

We here add unit tests in test_mappers.py along with a functional test
in test_api_misc.py.

This mapper has "jsonschema.item" regid, so it belongs to
mappers.collection module. We also rename it changing "inlined" into
composite since this is was it is (see selector). Since we lost the base
class we have to re-implement selection argument parsing and setting as
attribute, hence the new __init__ method.

It's probably not meant to be part of the public API but I need it
downstream at the moment.

Instead of duplicating the logic of serialization of items in this
method, we now rely on a dedicate "jsonschema.item" mapper (properly
selected with relation information) to serialize each item of the
relation.

Previously, the set of related entities was computed within
"jsonschema.relation" mappers and their serialize() method accepted only
the main "entity" from which this "related" set was computed. This is
asymmetric with "jsonschema.collection" which serialize() method handles
a list of entities. So we make the former mappers accept the set of
related directly as an argument to their serialize() method. This set is
computed by "jsonschema.entity" mapper.

This is a step forward merging "jsonschema.relation" mappers (for
non-final relation) with "jsonschema.collection" mappers.

This mapper cannot de-serialize values so it makes no sense to have it
produce a JSON Schema for "creation" role.

According to their regid.

The idea is to have only classes share the same regid in a given file,
and file named according to the "jsonschema.<name>" regid.

These use IJSONSchema adapter (which we want to get rid of) and are
redundant with other tests.

As noted inline in the comment, after commit() we have not real
guarantee that the relation we think has been inserted is actually there
(though it should be in most cases). For instance, hooks may have
modified data before the commit (case happen in client application).

In such cases, resource traversal from RelatedEntitiesResource (using
__getitem__) would fail with a KeyError so we cannot simply return a 201
Created. We instead return a 204 No Content as we have nothing to
return.

This is equivalent and just got left-over from prior refactorings.

We add an in_state (type: "string") property in the JSON instance and
schema of workflowable entity type. This property is read-only as it
does not match the underlying Yams schema (in which the target of
"in_state" relation is a State entity). This is not a problem since we
already have a way to manipulate the workflow state of entities through
the dedicated "tag:cubicweb.org,2017:workflow-transitions" hyper-link.

Closes #17135800.

Function find_relationship receives a "role" parameter but during the
loop on relation definitions we were overriding it with an eponymous
variable. Hence change loop variable name into "current_role".

This got unnoticed because, most of the times, "role" from parameter and
from loop would be the same. But for symmetric relation (an entity type
being allowed as both subject and object), this breaks.