- validation script used unmaintained npm package
- switched to actively maintained package from same maintainer
- pipe full output to stdout
- bump node major version in development backend Dockerfile
- fix two api spec errors and two random warnings - boyscout, hell yeah
Both are rendered through the ProjectRepresenter (because they are technically
implemented as Projects), but haven't been tested against it yet.
This also means that they still included required properties that were already
removed from the project schema (this was an error in the schema).
We generate those tokens with a prefix, so that we
can decide by looking at a token, whether it's an API Token
or a different kind of token, so that we can decide which
code path to choose for validating the token.
The usage of access tokens as Bearer token has the usability advantage,
that you can paste them as plaintext into tools that expect you
to specify the token as a header.
Also the Basic auth approach for our old tokens usually rather caused
issues, such as browsers prompting for credentials in surprising situations.
If we were to deprecate basic authentication one day, this change today could've
been the first step towards that.
Adds `GET /api/v3/projects/:id/configuration` endpoint that returns
all global configuration properties plus project-specific settings.
This allows client apps to check both enterprise token features
(availableFeatures) and project settings (enabledInternalComments)
in a single API call.
Those are usually linked through other OpenAPI specification
documents and different examples can refer to the same specification.
Fixed violations along the way, most of them were typos in either the
schema or the example. In one case a wrong schema was referenced, most likely
because the name was sufficiently confusing. The reference went to
`query_filter_instance_schema_model`, when it should have been `query_filter_instance_model`.
Sadly, the latter didn't even exist as a schema. I changed the reference and added a schema
based on what I could find in our implemented representer. It was consistent with examples.
All of them only contained a single example anyways. This
change immediately enabled validation of the example against
the schema in specs, which uncovered a wrong schema.
Examples and the implementation of the TimeEntryRepresenter
agreed that the comment was a formattable, but the schema claimed
it would be a string.
Our schemas often contain embedded examples that show what a representation
will look like.
These specs ensure that those embedded examples conform to the schema
that they are an example for.
Some collection examples contained abbreviated examples for what they look like.
To support these, the previously added _hint key was replaced with an explicit
_abbreviated key and examples that include this key are skipped.
In YAML, null is interpreted as a literal null value,
but we intended to use it as the string "null".
For consistency the first element of the array was also formatted
in double quotes and the array is now also formatted across
multiple lines.
Those self-tests are "basic" in the sense that they only validate
their compliance with our documented schema in one representation.
These test cases don't yet cover/validate whether the generated
representation also fulfills the schema under different circumstances,
for example when rendering for a user with fewer privileges, not allowed
to see certain fields.
Where necessary, the schema was changed to reflect the reality, e.g.
when those tests revealed that a "required" field might be missing due to
a lack of permissions.
In a few cases the implementation was adapted to allow for stricter guarantees
of the specified schema, for example links allowed to leave out the title key
already, so its not necessary to emit `title: nil` in cases where a title is
not known.
- hierarachy item now return a weight and a formatted weight in the API
response
- weight is the accurate value
- formatted weight is the value in display representation after standard
formatting
Eric Schubert