- 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).
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
- fix building the URL to hook up the Hocuspocus provider on Blocknote
- remove from documentation a field that should not be available yet on the API (should be released in future versions)
- add a feature flag check on the new documents PATCH endpoint, if it's not enabled we don't take requests yet
TIL that both "end point" and "endpoint" are valid,
but one source on the internet tells me that "endpoint"
is more commonly used and (more importantly) our code base
agrees. A case-sensitive search for "endpoint" gives me over
2000 results, over 300 of these are inside "docs/".
Eric Schubert