Summary:
Adds a Python function `REQUEST` which makes an HTTP GET request. Behind the scenes it:
- Raises a special exception to stop trying to evaluate the current cell and just keep the existing value.
- Notes the request arguments which will be returned by `apply_user_actions`.
- Makes the actual request in NodeJS, which sends back the raw response data in a new action `RespondToRequests` which reevaluates the cell(s) that made the request.
- Wraps the response data in a class which mimics the `Response` class of the `requests` library.
In certain cases, this asynchronous flow doesn't work and the sandbox will instead synchronously call an exported JS method:
- When reevaluating a single cell to get a formula error, the request is made synchronously.
- When a formula makes multiple requests, the earlier responses are retrieved synchronously from files which store responses as long as needed to complete evaluating formulas. See https://grist.slack.com/archives/CL1LQ8AT0/p1653399747810139
Test Plan: Added Python and nbrowser tests.
Reviewers: georgegevoian
Reviewed By: georgegevoian
Subscribers: paulfitz, dsagal
Differential Revision: https://phab.getgrist.com/D3429
Summary: This makes an equivalent of the /records REST endpoint available within custom widgets. For simple operations, it is compatible with https://github.com/airtable/airtable.js/. About half of the diff is refactoring code from DocApi that implements /records using applyUserActions, to make that code available in the plugin api.
Test Plan: added tests
Reviewers: alexmojaki
Reviewed By: alexmojaki
Differential Revision: https://phab.getgrist.com/D3320
Summary:
- Sharing, Client, DocClients, HostingStorageManager all include available info.
- In HostingStorageManager, log numSteps and maxStepTimeMs, in case that helps
debug SQLITE_BUSY problem.
- Replace some action-bundle logging with a JSON version aggregating some info.
- Skip logging detailed list of actions in production.
Test Plan: Tested manually by eyeballing log output in dev environment.
Reviewers: paulfitz
Reviewed By: paulfitz
Differential Revision: https://phab.getgrist.com/D3086
Summary:
Applies simple data transformations to the existing /data API.
Mimics the Airtable API. Designed in https://grist.quip.com/RZh9AEbPaj8x/Doc-API#FZfACAAZ9a0
Haven't done deletion because it seems like less of a priority and also not fully designed.
Test Plan: Added basic server tests similar to the /data tests. Haven't tested edge cases like bad input.
Reviewers: paulfitz
Reviewed By: paulfitz
Subscribers: dsagal
Differential Revision: https://phab.getgrist.com/D2974
Summary:
- Update rules to be more like we've had with tslint
- Switch tsserver plugin to eslint (tsserver makes for a much faster way to lint in editors)
- Apply suggested auto-fixes
- Fix all lint errors and warnings in core/, app/, test/
Test Plan: Some behavior may change subtly (e.g. added missing awaits), relying on existing tests to catch problems.
Reviewers: paulfitz
Reviewed By: paulfitz
Differential Revision: https://phab.getgrist.com/D2785
Summary:
This implements row-level access control for outgoing messages, replacing the document reloading placeholder that was there before.
* Prior to broadcasting messages, GranularAccess is notified of actions+undo.
* While broadcasting messages to different sessions, if we find we need row level access control information, rows before and after the change are reconstructed.
* Messages are rewritten if rows that were previously forbidden are now allowed, and vice versa.
The diff is somewhat under-tested and under-optimized. Next step would be to implement row-level access control for incoming actions, which may result in some rejiggering of the code from this diff to avoid duplication of effort under some conditions.
Test Plan: added test
Reviewers: dsagal
Reviewed By: dsagal
Differential Revision: https://phab.getgrist.com/D2670
Summary:
It can be hard to find changes, even when highlighted, in a table with many rows. This diff replaces long sequences of unchanged rows with a row containing "..."s.
With daff, I found that it is important to do this for sequences of unchanged columns also, but not tackling that yet.
Test Plan: added test
Reviewers: dsagal
Reviewed By: dsagal
Differential Revision: https://phab.getgrist.com/D2666
Summary:
Render simple differences between documents.
* Show cell changes.
* Show cell conflicts.
* Show row additions/deletions.
Doesn't support any schema changes, and is untested in the presence of schema changes. Any widgets that access row data without using `cells` fields won't receive correct data.
Not addressed:
* Rendering conflicts in mixed row addition/updating/deleting.
* Column additions/deletions, option changes, etc.
* Document level changes.
* Table and column renames (though anticipated in ActionSummary structure).
* Page-level changes.
* Drawing attention to changes (marking changed pages+views, suppressing
unchanged rows, etc).
* Rendering differences in views other than GridView.
* Adding UI for initiating a comparison.
* Editing while comparing.
Replaces {D2600}
Test Plan: added tests
Reviewers: dsagal
Reviewed By: dsagal
Differential Revision: https://phab.getgrist.com/D2618
Summary:
This simplifies writing custom widgets that access selected
data. To access the record at which the cursor is set, and
get any future changes to it as the cursor moves or data
changes, it suffices now to do:
```
grist.ready();
grist.onRecord(record => /* render */);
```
Similarly to access the set of selected records, and get any
changes, it suffices now to do:
```
grist.ready();
grist.onRecords(records => /* render */);
```
The `records` argument will be a list of objects, each of which
is a single record. This is distinct from the column-based
representation favored in Grist up ontil now. That remains
how methods like `fetchTable` or `fetchSelectedTable` represent
their results. In the future, methods named like `fetchRecords`
or `fetchSelectedRecords` could be added that return lists.
Test Plan: extended tests
Reviewers: dsagal
Reviewed By: dsagal
Differential Revision: https://phab.getgrist.com/D2583
Summary: This moves enough server material into core to run a home server. The data engine is not yet incorporated (though in manual testing it works when ported).
Test Plan: existing tests pass
Reviewers: dsagal
Reviewed By: dsagal
Differential Revision: https://phab.getgrist.com/D2552
