GitLab

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).

CubicWeb already prints captured logs in stderr upon test failure, so we
get them twice.

Previously, this was disallowed on view side because it was not
clear we actually wanted this. But now we need it!
So implement a similar mechanism to CubicWeb's ORM with a route segment
"reverse-<rtype>". We use a '-' because it does not pose problem in a
URL and it would never conflict with a real relation name as defined in
Yams.

Boilerplate.

For other kinds of JSON Schema (e.g. "array" or any final type), it does
not make sense and will not work.

The previous None value would be converted as null in JSON which does
not have this meaning (and is not even a valid JSON Schema).

Instead we now return False to indicate that there is no data for items
of the relation collection, so that when this "items" sub-schema is used
within a type: "array", validation will always fail (which in turns,
means that no entity creation is possible in such cases).

This permission (the name does not matter as we used ALL_PERMISSIONS on
resources in the previous changeset) makes all unauthenticated requests
on API views result in a "403 Forbidden". This is demonstrated in new
tests in test_api_permissions.py. In other tests, we have to login
before any such requests.

This __acl__ attribute defines the security rules for usage of all
resources in the tree with RootResource as root in views. (Views
permission is coming in the next changeset.) The first ACE (access
control element) states that we allow anything to authenticated users
while the second one states that we deny everything for everybody else.
This makes sense since we actually rely on CubicWeb's permission check
but we still need an authenticated user to perform this check. Such a
user may be anonymous or a regular account, it does not matter and
should be handled by CubicWeb permission system.

Ideally, we should only have done this on RootResource but
RelationshipResource (which we should drop, see #17086899) can exist
outside the resource tree with RootResource as root, so we also need to
repeat the __acl__ there.

This ensures that these methods are not called if the request is
unauthenticated, which would not work since request.cw_cnx is None in
this case. We issue a 403 Forbidden upon attempt to call these methods.

The latter is not really meaningful without the old CubicWeb application
handler (i.e. with "cubicweb.bwcompat = false").

cw_request attribute is still used elsewhere but that's a start.

JSON Schema validation of an instance is arguably the responsibility of
the client and it's not very useful to (re-)validate the instance on
server side with a JSON Schema validator since we already have a
validation in the database.

Also, it creates problems with combined usage of "default" and
"required" when the client does not supply a value (which is
legitimate). Closes #17115851. (Added a test for this.)

In ETypeMapper.values(), we now check that "instance" is completely
consumed when all mappers of the graph have been called and if not, we
issue a validation error similar to what a JSON Schema validator would
have raised since we have `"addionnalProperties": "false"` on our JSON
Schema.

There's no behaviour change in tests, just some error messages changes.
Useless tests are dropped.

We do not depend on python-jsonschema anymore in application code, but
only in tests.

--HG--
branch : 0.2

The latter works by using whatever python3 executable points to.

--HG--
branch : 0.2

For unauthenticated users, request.cw_cnx is None.

The latter works by using whatever python3 executable points to.