GitLab

This makes it match with previous change on POST handler of related
entities resource which accepts a single target resource.

We add an extra subclass NonInlinedRelatedCollectionMapper of
RelatedCollectionMapper which is selected when the relation is not
composite (whereas the latter is). In each of these classes, we override
the _submission_schema_and_definitions method so as to either return the
creation schema of a plain entity (case of a composite relation) or
return a schema (still of type="object") with restriction on the "id"
property to only allow *unrelated* targets.

We extract out the logic for submissionSchema generation from
schema_and_definitions() method into a
_submission_schema_and_definitions() method because we'll need to
override it in subclasses.

We are about to change the schema produced by 'jsonschema.collection'
mapper in the context of a relation but we are missing test coverage for
the case where the relation is "inlined" (e.g. the target is component
of the relation).

As we now only handle POST-ing single resource's representation, we can
return the created resource instead of 204 No Content. The location of
the created resource corresponds to the related entity, not the primary
URL of the entity.

This will allow to GET /<etype>/<eid>/reverse-<rtype>/<eid> routes. The
"reverse-" prefix is handled in traversal by setting the __name__ of
RelatedEntityResource according to specified role.

Test coverage comes in following changesets as we have no unit tests for
"resources".

These "related" routes (`/<etype>/<eid>/<rtype>`) actually represent
collections of (related) entities. However, JSON Hyper Schema recommends
that POST-ing to a collection should be made with a single resource
(i.e. an item to be added to the collection). Previously these routes
accepted an array of items so we here change this so that it accepts a
single resource.

As there exists no standard relation type to describe "workflow
transitions", we use a custom tag: URI scheme as recommended by JSON
Hyper Schema specification.

This simplifies the setup a bit as we do not have to retrieve CWGroup
choices as before to create a CWUser.

This will be used to work with workflows in a simpler way than CWUser
entity type which schema is a lot more complex.

We always use `indent=2` (even for the diff output) and use `sort_keys`
option of json.dumps().

In test_json_body_differ we have to work around a difference in
json.dumps() between Python 2 and Python 3 as the former apparently
yields trailing whitespaces sometimes.

Introduce a DOCTESTS_PATTERN environment variable to select .rst files
to be added as doctests. I could not find another way to make this
possible.

This relies on a collect_links() method which has been dropped in
819b57b21a50. Given this is not covered by test, better remove that
code.

We associate the proper 'jsonschema.collection' mapper from the
WorkflowTransitionsResource resource by implementing the mapper()
method.

Most added views are straightforward except the
post_entity_workflow_transition which handles adapter.fire_transition()
call directly (instead of passing through mapper.values()) since, as
noted in previous changeset we diverge from the actual implementation of
workflows in CubicWeb to expose a simpler REST API.

See functional tests for how it works.

We add two mappers corresponding to the TrInfo entity type:

* TrInfoEntityMapper is used for JSON Schema generation with "creation"
  role; this schema is different from what the normal mapper would
  produce in that it exposes the "name" of the transition directly and
  hides the implementation details of CubicWeb's workflows (which is a
  state machine not really needed in the framework of a REST API).

* TrInfoCollectionMapper is a collection mapper that only supports
  serialization and produces the array of transitions fired for the
  entity given in context.

I.e. do not assume that all mappers will also register some Link
appobjects with the same regid.

As in previous patch, we delegate this to 'jsonschema.entity' mapper.

This is in preparation of always using the same mapper (i.e.
'jsonschema.collection') for an entity collection resource
(ETypeResource).

We need to preserve the previous behavior for RelatedCollectionMapper
that inherits from EntityCollectionMapper, so we factor out the '"type":
"array"' schema into an _array_schema() method.

Runs faster when iterating locally.

This pattern was borrowed from JSON:API (http://jsonapi.org/) and was
kept because we lacked a way to create reverse-relations before
b1c524d64381.

Closes #17086899.

We want to get rid of adapters in entities view as we did for schema
views. The aim is to have a uniform way of retrieving a mapper object
from the route context (using context.mapper()).

In this branch, server-side JSON Schema validation got dropped. However,
we still need some kind of validation in order to return a proper bad
request error in HTTP API (instead of an Internal Server Error). Hence,
we introduce an extra validation step in RelationMapper.values() to keep
test_api_misc.py working (though with a different error message). Also
notice the change in test_post_related_bad_target where the payload was
badly formatted (should have been a list of dicts) and is now fixed.

Define the Mappable interface for RelatedEntitiesResource and use it in related_entities_schema view

Such resources would have a "mapper" method which should be the
preferred way of retrieving mapper objects in API views.

Most of the times, it's handy to have the "resource" (context of the
Pyramid view) passed down to mappers, so pass it automatically in
select_mapper().

The only case where we (currently) avoid passing the "resource" is for
inlined and non-composite relation (such as author-subject, w.r.t.
tests' schema), because this would generate a rel="item" link with the
wrong href (because of the hard-coded value in respective Link).