Summary:
A new set of endpoints for managing installation and site configuration have been added:
- GET `/api/install/configs/:key` - get the value of the configuration item with the specified key
- PUT `/api/install/configs/:key` - set the value of the configuration item with the specified key
- body: the JSON value of the configuration item
- DELETE `/api/install/configs/:key` - delete the configuration item with the specified key
- GET `/api/orgs/:oid/configs/:key` - get the value of the configuration item with the specified key
- PUT `/api/orgs/:oid/configs/:key` - set the value of the configuration item with the specified key
- body: the JSON value of the configuration item
- DELETE `/api/orgs/:oid/configs/:key` - delete the configuration item with the specified key
Configuration consists of key/value pairs, where keys are strings (e.g. `"audit_logs_streaming_destinations"`) and values are JSON, including literals like numbers and strings. Only installation admins and site owners are permitted to modify installation and site configuration, respectively.
The endpoints are planned to be used in an upcoming feature for enabling audit log streaming for an installation and/or site. Future functionality may use the endpoints as well, which may require extending the current capabilities (e.g. adding support for storing secrets, additional metadata fields, etc.).
Test Plan: Server tests
Reviewers: paulfitz, jarek
Reviewed By: paulfitz, jarek
Subscribers: jarek
Differential Revision: https://phab.getgrist.com/D4377
This checks whether code can successfully run in the
sandbox only when the admin panel needs to report that,
rather than at start up. This is motivated by two things:
- The desktop app became a lot slower to open with this
check, since it uses pyodide by default, and there's
been no work on optimizing the pyodide sandbox load
times (as opposed to gvisor, where a lot of work was
done, and it is also fundamentally faster).
- The messages logged by a test sandbox starting and
stopping have been confusing people.
There is a case for doing the check on startup, especially
on servers, so that we can fail early. Still, that isn't
what we were doing, and we'd also like to move away from the
server refusing to start because of a problem and
towards an always-reachable admin page that reports
the nature of problems in a clearer way.
Make a set of changes required for Desktop FS improvements, see
https://github.com/gristlabs/grist-desktop/pull/42
---------
Co-authored-by: Spoffy <contact@spoffy.net>
Co-authored-by: Spoffy <4805393+Spoffy@users.noreply.github.com>
