2020-11-17 21:49:32 +00:00
|
|
|
/*** THIS FILE IS AUTO-GENERATED BY core/sandbox/gen_js_schema.py ***/
|
2021-10-07 21:02:51 +00:00
|
|
|
|
|
|
|
import { GristObjCode } from "app/plugin/GristData";
|
|
|
|
|
2020-07-21 13:20:51 +00:00
|
|
|
// tslint:disable:object-literal-key-quotes
|
|
|
|
|
(core) Adding backend for 2-way references
Summary:
Adding support for 2-way references in data engine.
- Columns have an `reverseCol` field, which says "this is a reverse of the given column, update me when that one changes".
- At the time of setting `reverseCol`, we ensure that it's symmetrical to make a 2-way reference.
- Elsewhere we just implement syncing in one direction:
- When `reverseCol` is present, user code is generated with a type like `grist.ReferenceList("Tasks", reverse_of="Assignee")`
- On updating a ref column, we use `prepare_new_values()` method to generate corresponding updates to any column that's a reverse of it.
- The `prepare_new_values()` approach is extended to support this.
- We don't add (or remove) any mappings between rows, and rely on existing mappings (in a ref column's `_relation`) to create reverse updates.
NOTE This is polished version of https://phab.getgrist.com/D4307 with tests and 3 bug fixes
- Column transformation didn't work when transforming RefList to Ref, the reverse column became out of sync
- Tables with reverse columns couldn't be removed
- Setting json arrays to RefList didn't work if arrays contained other things besides ints
Those fixes are covered by new tests.
Test Plan: New tests
Reviewers: georgegevoian, paulfitz, dsagal
Reviewed By: georgegevoian, paulfitz
Subscribers: dsagal
Differential Revision: https://phab.getgrist.com/D4322
2024-09-09 16:24:11 +00:00
|
|
|
export const SCHEMA_VERSION = 43;
|
2021-10-01 13:45:27 +00:00
|
|
|
|
2020-07-21 13:20:51 +00:00
|
|
|
export const schema = {
|
|
|
|
|
|
|
|
"_grist_DocInfo": {
|
|
|
|
docId : "Text",
|
|
|
|
peers : "Text",
|
|
|
|
basketId : "Text",
|
|
|
|
schemaVersion : "Int",
|
|
|
|
timezone : "Text",
|
2021-08-26 16:35:11 +00:00
|
|
|
documentSettings : "Text",
|
2020-07-21 13:20:51 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
"_grist_Tables": {
|
|
|
|
tableId : "Text",
|
|
|
|
primaryViewId : "Ref:_grist_Views",
|
|
|
|
summarySourceTable : "Ref:_grist_Tables",
|
|
|
|
onDemand : "Bool",
|
2022-02-01 18:48:39 +00:00
|
|
|
rawViewSectionRef : "Ref:_grist_Views_section",
|
2023-11-20 00:46:32 +00:00
|
|
|
recordCardViewSectionRef: "Ref:_grist_Views_section",
|
2020-07-21 13:20:51 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
"_grist_Tables_column": {
|
|
|
|
parentId : "Ref:_grist_Tables",
|
|
|
|
parentPos : "PositionNumber",
|
|
|
|
colId : "Text",
|
|
|
|
type : "Text",
|
|
|
|
widgetOptions : "Text",
|
|
|
|
isFormula : "Bool",
|
|
|
|
formula : "Text",
|
|
|
|
label : "Text",
|
2023-01-24 13:30:14 +00:00
|
|
|
description : "Text",
|
2020-07-21 13:20:51 +00:00
|
|
|
untieColIdFromLabel : "Bool",
|
|
|
|
summarySourceCol : "Ref:_grist_Tables_column",
|
|
|
|
displayCol : "Ref:_grist_Tables_column",
|
|
|
|
visibleCol : "Ref:_grist_Tables_column",
|
2022-03-22 13:41:11 +00:00
|
|
|
rules : "RefList:_grist_Tables_column",
|
(core) Adding backend for 2-way references
Summary:
Adding support for 2-way references in data engine.
- Columns have an `reverseCol` field, which says "this is a reverse of the given column, update me when that one changes".
- At the time of setting `reverseCol`, we ensure that it's symmetrical to make a 2-way reference.
- Elsewhere we just implement syncing in one direction:
- When `reverseCol` is present, user code is generated with a type like `grist.ReferenceList("Tasks", reverse_of="Assignee")`
- On updating a ref column, we use `prepare_new_values()` method to generate corresponding updates to any column that's a reverse of it.
- The `prepare_new_values()` approach is extended to support this.
- We don't add (or remove) any mappings between rows, and rely on existing mappings (in a ref column's `_relation`) to create reverse updates.
NOTE This is polished version of https://phab.getgrist.com/D4307 with tests and 3 bug fixes
- Column transformation didn't work when transforming RefList to Ref, the reverse column became out of sync
- Tables with reverse columns couldn't be removed
- Setting json arrays to RefList didn't work if arrays contained other things besides ints
Those fixes are covered by new tests.
Test Plan: New tests
Reviewers: georgegevoian, paulfitz, dsagal
Reviewed By: georgegevoian, paulfitz
Subscribers: dsagal
Differential Revision: https://phab.getgrist.com/D4322
2024-09-09 16:24:11 +00:00
|
|
|
reverseCol : "Ref:_grist_Tables_column",
|
2021-06-29 04:47:59 +00:00
|
|
|
recalcWhen : "Int",
|
(core) Implement trigger formulas (generalizing default formulas)
Summary:
Trigger formulas can be calculated for new records, or for new records and
updates to certain fields, or all fields. They do not recalculate on open,
and they MAY be set directly by the user, including for data-cleaning.
- Column metadata now includes recalcWhen and recalcDeps fields.
- Trigger formulas are NOT recalculated on open or on schema changes.
- When recalcWhen is "never", formula isn't calculated even for new records.
- When recalcWhen is "allupdates", formula is calculated for new records and
any manual (non-formula) updates to the record.
- When recalcWhen is "", formula is calculated for new records, and changes to
recalcDeps fields (which may be formula fields or column itself).
- A column whose recalcDeps includes itself is a "data-cleaning" column; a
value set by the user will still trigger the formula.
- All trigger-formulas receive a "value" argument (to support the case above).
Small changes
- Update RefLists (used for recalcDeps) when target rows are deleted.
- Add RecordList.__contains__ (for `rec in refList` or `id in refList` checks)
- Clarify that Calculate action has replaced load_done() in practice,
and use it in tests too, to better match reality.
Left for later:
- UI for setting recalcWhen / recalcDeps.
- Implementation of actions such as "Recalculate for all cells".
- Allowing trigger-formulas access to the current user's info.
Test Plan: Added a comprehensive python-side test for various trigger combinations
Reviewers: paulfitz, alexmojaki
Reviewed By: paulfitz
Differential Revision: https://phab.getgrist.com/D2872
2021-06-25 20:34:20 +00:00
|
|
|
recalcDeps : "RefList:_grist_Tables_column",
|
2020-07-21 13:20:51 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
"_grist_Imports": {
|
|
|
|
tableRef : "Ref:_grist_Tables",
|
|
|
|
origFileName : "Text",
|
|
|
|
parseFormula : "Text",
|
|
|
|
delimiter : "Text",
|
|
|
|
doublequote : "Bool",
|
|
|
|
escapechar : "Text",
|
|
|
|
quotechar : "Text",
|
|
|
|
skipinitialspace : "Bool",
|
|
|
|
encoding : "Text",
|
|
|
|
hasHeaders : "Bool",
|
|
|
|
},
|
|
|
|
|
|
|
|
"_grist_External_database": {
|
|
|
|
host : "Text",
|
|
|
|
port : "Int",
|
|
|
|
username : "Text",
|
|
|
|
dialect : "Text",
|
|
|
|
database : "Text",
|
|
|
|
storage : "Text",
|
|
|
|
},
|
|
|
|
|
|
|
|
"_grist_External_table": {
|
|
|
|
tableRef : "Ref:_grist_Tables",
|
|
|
|
databaseRef : "Ref:_grist_External_database",
|
|
|
|
tableName : "Text",
|
|
|
|
},
|
|
|
|
|
|
|
|
"_grist_TableViews": {
|
|
|
|
tableRef : "Ref:_grist_Tables",
|
|
|
|
viewRef : "Ref:_grist_Views",
|
|
|
|
},
|
|
|
|
|
|
|
|
"_grist_TabItems": {
|
|
|
|
tableRef : "Ref:_grist_Tables",
|
|
|
|
viewRef : "Ref:_grist_Views",
|
|
|
|
},
|
|
|
|
|
|
|
|
"_grist_TabBar": {
|
|
|
|
viewRef : "Ref:_grist_Views",
|
|
|
|
tabPos : "PositionNumber",
|
|
|
|
},
|
|
|
|
|
|
|
|
"_grist_Pages": {
|
|
|
|
viewRef : "Ref:_grist_Views",
|
|
|
|
indentation : "Int",
|
|
|
|
pagePos : "PositionNumber",
|
(core) add initial support for special shares
Summary:
This gives a mechanism for controlling access control within a document that is distinct from (though implemented with the same machinery as) granular access rules.
It was hard to find a good way to insert this that didn't dissolve in a soup of complications, so here's what I went with:
* When reading rules, if there are shares, extra rules are added.
* If there are shares, all rules are made conditional on a "ShareRef" user property.
* "ShareRef" is null when a doc is accessed in normal way, and the row id of a share when accessed via a share.
There's no UI for controlling shares (George is working on it for forms), but you can do it by editing a `_grist_Shares` table in a document. Suppose you make a fresh document with a single page/table/widget, then to create an empty share you can do:
```
gristDocPageModel.gristDoc.get().docData.sendAction(['AddRecord', '_grist_Shares', null, {linkId: 'xyz', options: '{"publish": true}'}])
```
If you look at the home db now there should be something in the `shares` table:
```
$ sqlite3 -table landing.db "select * from shares"
+----+------------------------+------------------------+--------------+---------+
| id | key | doc_id | link_id | options |
+----+------------------------+------------------------+--------------+---------+
| 1 | gSL4g38PsyautLHnjmXh2K | 4qYuace1xP2CTcPunFdtan | xyz | ... |
+----+------------------------+------------------------+--------------+---------+
```
If you take the key from that (gSL4g38PsyautLHnjmXh2K in this case) and replace the document's urlId in its URL with `s.<key>` (in this case `s.gSL4g38PsyautLHnjmXh2K` then you can use the regular document landing page (it will be quite blank initially) or API endpoint via the share.
E.g. for me `http://localhost:8080/o/docs/s0gSL4g38PsyautLHnjmXh2K/share-inter-3` accesses the doc.
To actually share some material - useful commands:
```
gristDocPageModel.gristDoc.get().docData.getMetaTable('_grist_Views_section').getRecords()
gristDocPageModel.gristDoc.get().docData.sendAction(['UpdateRecord', '_grist_Views_section', 1, {shareOptions: '{"publish": true, "form": true}'}])
gristDocPageModel.gristDoc.get().docData.getMetaTable('_grist_Pages').getRecords()
gristDocPageModel.gristDoc.get().docData.sendAction(['UpdateRecord', '_grist_Pages', 1, {shareRef: 1}])
```
For a share to be effective, at least one page needs to have its shareRef set to the rowId of the share, and at least one widget on one of those pages needs to have its shareOptions set to {"publish": "true", "form": "true"} (meaning turn on sharing, and include form sharing), and the share itself needs {"publish": true} on its options.
I think special shares are kind of incompatible with public sharing, since by their nature (allowing access to all endpoints) they easily expose the docId, and changing that would be hard.
Test Plan: tests added
Reviewers: dsagal, georgegevoian
Reviewed By: dsagal, georgegevoian
Subscribers: jarek, dsagal
Differential Revision: https://phab.getgrist.com/D4144
2024-01-03 16:53:20 +00:00
|
|
|
shareRef : "Ref:_grist_Shares",
|
2020-07-21 13:20:51 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
"_grist_Views": {
|
|
|
|
name : "Text",
|
|
|
|
type : "Text",
|
|
|
|
layoutSpec : "Text",
|
|
|
|
},
|
|
|
|
|
|
|
|
"_grist_Views_section": {
|
|
|
|
tableRef : "Ref:_grist_Tables",
|
|
|
|
parentId : "Ref:_grist_Views",
|
|
|
|
parentKey : "Text",
|
|
|
|
title : "Text",
|
2023-05-15 15:16:58 +00:00
|
|
|
description : "Text",
|
2020-07-21 13:20:51 +00:00
|
|
|
defaultWidth : "Int",
|
|
|
|
borderWidth : "Int",
|
|
|
|
theme : "Text",
|
|
|
|
options : "Text",
|
|
|
|
chartType : "Text",
|
|
|
|
layoutSpec : "Text",
|
|
|
|
filterSpec : "Text",
|
|
|
|
sortColRefs : "Text",
|
|
|
|
linkSrcSectionRef : "Ref:_grist_Views_section",
|
|
|
|
linkSrcColRef : "Ref:_grist_Tables_column",
|
|
|
|
linkTargetColRef : "Ref:_grist_Tables_column",
|
|
|
|
embedId : "Text",
|
2022-08-08 13:32:50 +00:00
|
|
|
rules : "RefList:_grist_Tables_column",
|
(core) add initial support for special shares
Summary:
This gives a mechanism for controlling access control within a document that is distinct from (though implemented with the same machinery as) granular access rules.
It was hard to find a good way to insert this that didn't dissolve in a soup of complications, so here's what I went with:
* When reading rules, if there are shares, extra rules are added.
* If there are shares, all rules are made conditional on a "ShareRef" user property.
* "ShareRef" is null when a doc is accessed in normal way, and the row id of a share when accessed via a share.
There's no UI for controlling shares (George is working on it for forms), but you can do it by editing a `_grist_Shares` table in a document. Suppose you make a fresh document with a single page/table/widget, then to create an empty share you can do:
```
gristDocPageModel.gristDoc.get().docData.sendAction(['AddRecord', '_grist_Shares', null, {linkId: 'xyz', options: '{"publish": true}'}])
```
If you look at the home db now there should be something in the `shares` table:
```
$ sqlite3 -table landing.db "select * from shares"
+----+------------------------+------------------------+--------------+---------+
| id | key | doc_id | link_id | options |
+----+------------------------+------------------------+--------------+---------+
| 1 | gSL4g38PsyautLHnjmXh2K | 4qYuace1xP2CTcPunFdtan | xyz | ... |
+----+------------------------+------------------------+--------------+---------+
```
If you take the key from that (gSL4g38PsyautLHnjmXh2K in this case) and replace the document's urlId in its URL with `s.<key>` (in this case `s.gSL4g38PsyautLHnjmXh2K` then you can use the regular document landing page (it will be quite blank initially) or API endpoint via the share.
E.g. for me `http://localhost:8080/o/docs/s0gSL4g38PsyautLHnjmXh2K/share-inter-3` accesses the doc.
To actually share some material - useful commands:
```
gristDocPageModel.gristDoc.get().docData.getMetaTable('_grist_Views_section').getRecords()
gristDocPageModel.gristDoc.get().docData.sendAction(['UpdateRecord', '_grist_Views_section', 1, {shareOptions: '{"publish": true, "form": true}'}])
gristDocPageModel.gristDoc.get().docData.getMetaTable('_grist_Pages').getRecords()
gristDocPageModel.gristDoc.get().docData.sendAction(['UpdateRecord', '_grist_Pages', 1, {shareRef: 1}])
```
For a share to be effective, at least one page needs to have its shareRef set to the rowId of the share, and at least one widget on one of those pages needs to have its shareOptions set to {"publish": "true", "form": "true"} (meaning turn on sharing, and include form sharing), and the share itself needs {"publish": true} on its options.
I think special shares are kind of incompatible with public sharing, since by their nature (allowing access to all endpoints) they easily expose the docId, and changing that would be hard.
Test Plan: tests added
Reviewers: dsagal, georgegevoian
Reviewed By: dsagal, georgegevoian
Subscribers: jarek, dsagal
Differential Revision: https://phab.getgrist.com/D4144
2024-01-03 16:53:20 +00:00
|
|
|
shareOptions : "Text",
|
2020-07-21 13:20:51 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
"_grist_Views_section_field": {
|
|
|
|
parentId : "Ref:_grist_Views_section",
|
|
|
|
parentPos : "PositionNumber",
|
|
|
|
colRef : "Ref:_grist_Tables_column",
|
|
|
|
width : "Int",
|
|
|
|
widgetOptions : "Text",
|
|
|
|
displayCol : "Ref:_grist_Tables_column",
|
|
|
|
visibleCol : "Ref:_grist_Tables_column",
|
|
|
|
filter : "Text",
|
2022-03-22 13:41:11 +00:00
|
|
|
rules : "RefList:_grist_Tables_column",
|
2020-07-21 13:20:51 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
"_grist_Validations": {
|
|
|
|
formula : "Text",
|
|
|
|
name : "Text",
|
|
|
|
tableRef : "Int",
|
|
|
|
},
|
|
|
|
|
|
|
|
"_grist_REPL_Hist": {
|
|
|
|
code : "Text",
|
|
|
|
outputText : "Text",
|
|
|
|
errorText : "Text",
|
|
|
|
},
|
|
|
|
|
|
|
|
"_grist_Attachments": {
|
|
|
|
fileIdent : "Text",
|
|
|
|
fileName : "Text",
|
|
|
|
fileType : "Text",
|
|
|
|
fileSize : "Int",
|
2023-04-06 15:10:29 +00:00
|
|
|
fileExt : "Text",
|
2020-07-21 13:20:51 +00:00
|
|
|
imageHeight : "Int",
|
|
|
|
imageWidth : "Int",
|
2022-04-01 21:55:59 +00:00
|
|
|
timeDeleted : "DateTime",
|
2020-07-21 13:20:51 +00:00
|
|
|
timeUploaded : "DateTime",
|
|
|
|
},
|
|
|
|
|
(core) Initial webhooks implementation
Summary:
See https://grist.quip.com/VKd3ASF99ezD/Outgoing-Webhooks
- 2 new DocApi endpoints: _subscribe and _unsubscribe, not meant to be user friendly or publicly documented. _unsubscribe should be given the response from _subscribe in the body, e.g:
```
$ curl -X POST -H "Authorization: Bearer 8fd4dc59ecb05ab29ae5a183c03101319b8e6ca9" "http://localhost:8080/api/docs/6WYa23FqWxGNe3AR6DLjCJ/tables/Table2/_subscribe" -H "Content-type: application/json" -d '{"url": "https://webhook.site/a916b526-8afc-46e6-aa8f-a625d0d83ec3", "eventTypes": ["add"], "isReadyColumn": "C"}'
{"unsubscribeKey":"3246f158-55b5-4fc7-baa5-093b75ffa86c","triggerId":2,"webhookId":"853b4bfa-9d39-4639-aa33-7d45354903c0"}
$ curl -X POST -H "Authorization: Bearer 8fd4dc59ecb05ab29ae5a183c03101319b8e6ca9" "http://localhost:8080/api/docs/6WYa23FqWxGNe3AR6DLjCJ/tables/Table2/_unsubscribe" -H "Content-type: application/json" -d '{"unsubscribeKey":"3246f158-55b5-4fc7-baa5-093b75ffa86c","triggerId":2,"webhookId":"853b4bfa-9d39-4639-aa33-7d45354903c0"}'
{"success":true}
```
- New DB entity Secret to hold the webhook URL and unsubscribe key
- New document metatable _grist_Triggers subscribes to table changes and points to a secret to use for a webhook
- New file Triggers.ts processes action summaries and uses the two new tables to send webhooks.
- Also went on a bit of a diversion and made a typesafe subclass of TableData for metatables.
I think this is essentially good enough for a first diff, to keep the diffs manageable and to talk about the overall structure. Future diffs can add tests and more robustness using redis etc. After this diff I can also start building the Zapier integration privately.
Test Plan: Tested manually: see curl commands in summary for an example. Payloads can be seen in https://webhook.site/#!/a916b526-8afc-46e6-aa8f-a625d0d83ec3/0b9fe335-33f7-49fe-b90b-2db5ba53382d/1 . Great site for testing webhooks btw.
Reviewers: dsagal, paulfitz
Reviewed By: paulfitz
Differential Revision: https://phab.getgrist.com/D3019
2021-09-22 23:06:23 +00:00
|
|
|
"_grist_Triggers": {
|
|
|
|
tableRef : "Ref:_grist_Tables",
|
|
|
|
eventTypes : "ChoiceList",
|
|
|
|
isReadyColRef : "Ref:_grist_Tables_column",
|
|
|
|
actions : "Text",
|
2023-05-08 22:06:24 +00:00
|
|
|
label : "Text",
|
|
|
|
memo : "Text",
|
|
|
|
enabled : "Bool",
|
2024-04-12 20:04:37 +00:00
|
|
|
watchedColRefList : "RefList:_grist_Tables_column",
|
|
|
|
options : "Text",
|
(core) Initial webhooks implementation
Summary:
See https://grist.quip.com/VKd3ASF99ezD/Outgoing-Webhooks
- 2 new DocApi endpoints: _subscribe and _unsubscribe, not meant to be user friendly or publicly documented. _unsubscribe should be given the response from _subscribe in the body, e.g:
```
$ curl -X POST -H "Authorization: Bearer 8fd4dc59ecb05ab29ae5a183c03101319b8e6ca9" "http://localhost:8080/api/docs/6WYa23FqWxGNe3AR6DLjCJ/tables/Table2/_subscribe" -H "Content-type: application/json" -d '{"url": "https://webhook.site/a916b526-8afc-46e6-aa8f-a625d0d83ec3", "eventTypes": ["add"], "isReadyColumn": "C"}'
{"unsubscribeKey":"3246f158-55b5-4fc7-baa5-093b75ffa86c","triggerId":2,"webhookId":"853b4bfa-9d39-4639-aa33-7d45354903c0"}
$ curl -X POST -H "Authorization: Bearer 8fd4dc59ecb05ab29ae5a183c03101319b8e6ca9" "http://localhost:8080/api/docs/6WYa23FqWxGNe3AR6DLjCJ/tables/Table2/_unsubscribe" -H "Content-type: application/json" -d '{"unsubscribeKey":"3246f158-55b5-4fc7-baa5-093b75ffa86c","triggerId":2,"webhookId":"853b4bfa-9d39-4639-aa33-7d45354903c0"}'
{"success":true}
```
- New DB entity Secret to hold the webhook URL and unsubscribe key
- New document metatable _grist_Triggers subscribes to table changes and points to a secret to use for a webhook
- New file Triggers.ts processes action summaries and uses the two new tables to send webhooks.
- Also went on a bit of a diversion and made a typesafe subclass of TableData for metatables.
I think this is essentially good enough for a first diff, to keep the diffs manageable and to talk about the overall structure. Future diffs can add tests and more robustness using redis etc. After this diff I can also start building the Zapier integration privately.
Test Plan: Tested manually: see curl commands in summary for an example. Payloads can be seen in https://webhook.site/#!/a916b526-8afc-46e6-aa8f-a625d0d83ec3/0b9fe335-33f7-49fe-b90b-2db5ba53382d/1 . Great site for testing webhooks btw.
Reviewers: dsagal, paulfitz
Reviewed By: paulfitz
Differential Revision: https://phab.getgrist.com/D3019
2021-09-22 23:06:23 +00:00
|
|
|
},
|
|
|
|
|
2020-07-21 13:20:51 +00:00
|
|
|
"_grist_ACLRules": {
|
|
|
|
resource : "Ref:_grist_ACLResources",
|
|
|
|
permissions : "Int",
|
|
|
|
principals : "Text",
|
|
|
|
aclFormula : "Text",
|
|
|
|
aclColumn : "Ref:_grist_Tables_column",
|
2020-11-17 21:49:32 +00:00
|
|
|
aclFormulaParsed : "Text",
|
|
|
|
permissionsText : "Text",
|
|
|
|
rulePos : "PositionNumber",
|
|
|
|
userAttributes : "Text",
|
2022-12-12 06:29:20 +00:00
|
|
|
memo : "Text",
|
2020-07-21 13:20:51 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
"_grist_ACLResources": {
|
|
|
|
tableId : "Text",
|
|
|
|
colIds : "Text",
|
|
|
|
},
|
|
|
|
|
|
|
|
"_grist_ACLPrincipals": {
|
|
|
|
type : "Text",
|
|
|
|
userEmail : "Text",
|
|
|
|
userName : "Text",
|
|
|
|
groupName : "Text",
|
|
|
|
instanceId : "Text",
|
|
|
|
},
|
|
|
|
|
|
|
|
"_grist_ACLMemberships": {
|
|
|
|
parent : "Ref:_grist_ACLPrincipals",
|
|
|
|
child : "Ref:_grist_ACLPrincipals",
|
|
|
|
},
|
|
|
|
|
2021-11-19 20:30:11 +00:00
|
|
|
"_grist_Filters": {
|
|
|
|
viewSectionRef : "Ref:_grist_Views_section",
|
|
|
|
colRef : "Ref:_grist_Tables_column",
|
|
|
|
filter : "Text",
|
2022-11-17 20:17:51 +00:00
|
|
|
pinned : "Bool",
|
2021-11-19 20:30:11 +00:00
|
|
|
},
|
|
|
|
|
2022-10-17 09:47:16 +00:00
|
|
|
"_grist_Cells": {
|
|
|
|
tableRef : "Ref:_grist_Tables",
|
|
|
|
colRef : "Ref:_grist_Tables_column",
|
|
|
|
rowId : "Int",
|
|
|
|
root : "Bool",
|
|
|
|
parentId : "Ref:_grist_Cells",
|
|
|
|
type : "Int",
|
|
|
|
content : "Text",
|
|
|
|
userRef : "Text",
|
|
|
|
},
|
|
|
|
|
(core) add initial support for special shares
Summary:
This gives a mechanism for controlling access control within a document that is distinct from (though implemented with the same machinery as) granular access rules.
It was hard to find a good way to insert this that didn't dissolve in a soup of complications, so here's what I went with:
* When reading rules, if there are shares, extra rules are added.
* If there are shares, all rules are made conditional on a "ShareRef" user property.
* "ShareRef" is null when a doc is accessed in normal way, and the row id of a share when accessed via a share.
There's no UI for controlling shares (George is working on it for forms), but you can do it by editing a `_grist_Shares` table in a document. Suppose you make a fresh document with a single page/table/widget, then to create an empty share you can do:
```
gristDocPageModel.gristDoc.get().docData.sendAction(['AddRecord', '_grist_Shares', null, {linkId: 'xyz', options: '{"publish": true}'}])
```
If you look at the home db now there should be something in the `shares` table:
```
$ sqlite3 -table landing.db "select * from shares"
+----+------------------------+------------------------+--------------+---------+
| id | key | doc_id | link_id | options |
+----+------------------------+------------------------+--------------+---------+
| 1 | gSL4g38PsyautLHnjmXh2K | 4qYuace1xP2CTcPunFdtan | xyz | ... |
+----+------------------------+------------------------+--------------+---------+
```
If you take the key from that (gSL4g38PsyautLHnjmXh2K in this case) and replace the document's urlId in its URL with `s.<key>` (in this case `s.gSL4g38PsyautLHnjmXh2K` then you can use the regular document landing page (it will be quite blank initially) or API endpoint via the share.
E.g. for me `http://localhost:8080/o/docs/s0gSL4g38PsyautLHnjmXh2K/share-inter-3` accesses the doc.
To actually share some material - useful commands:
```
gristDocPageModel.gristDoc.get().docData.getMetaTable('_grist_Views_section').getRecords()
gristDocPageModel.gristDoc.get().docData.sendAction(['UpdateRecord', '_grist_Views_section', 1, {shareOptions: '{"publish": true, "form": true}'}])
gristDocPageModel.gristDoc.get().docData.getMetaTable('_grist_Pages').getRecords()
gristDocPageModel.gristDoc.get().docData.sendAction(['UpdateRecord', '_grist_Pages', 1, {shareRef: 1}])
```
For a share to be effective, at least one page needs to have its shareRef set to the rowId of the share, and at least one widget on one of those pages needs to have its shareOptions set to {"publish": "true", "form": "true"} (meaning turn on sharing, and include form sharing), and the share itself needs {"publish": true} on its options.
I think special shares are kind of incompatible with public sharing, since by their nature (allowing access to all endpoints) they easily expose the docId, and changing that would be hard.
Test Plan: tests added
Reviewers: dsagal, georgegevoian
Reviewed By: dsagal, georgegevoian
Subscribers: jarek, dsagal
Differential Revision: https://phab.getgrist.com/D4144
2024-01-03 16:53:20 +00:00
|
|
|
"_grist_Shares": {
|
|
|
|
linkId : "Text",
|
|
|
|
options : "Text",
|
|
|
|
label : "Text",
|
|
|
|
description : "Text",
|
|
|
|
},
|
|
|
|
|
2020-07-21 13:20:51 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
export interface SchemaTypes {
|
|
|
|
|
|
|
|
"_grist_DocInfo": {
|
|
|
|
docId: string;
|
|
|
|
peers: string;
|
|
|
|
basketId: string;
|
|
|
|
schemaVersion: number;
|
|
|
|
timezone: string;
|
2021-08-26 16:35:11 +00:00
|
|
|
documentSettings: string;
|
2020-07-21 13:20:51 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
"_grist_Tables": {
|
|
|
|
tableId: string;
|
|
|
|
primaryViewId: number;
|
|
|
|
summarySourceTable: number;
|
|
|
|
onDemand: boolean;
|
2022-02-01 18:48:39 +00:00
|
|
|
rawViewSectionRef: number;
|
2023-11-20 00:46:32 +00:00
|
|
|
recordCardViewSectionRef: number;
|
2020-07-21 13:20:51 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
"_grist_Tables_column": {
|
|
|
|
parentId: number;
|
|
|
|
parentPos: number;
|
|
|
|
colId: string;
|
|
|
|
type: string;
|
|
|
|
widgetOptions: string;
|
|
|
|
isFormula: boolean;
|
|
|
|
formula: string;
|
|
|
|
label: string;
|
2023-01-19 11:37:31 +00:00
|
|
|
description: string;
|
2020-07-21 13:20:51 +00:00
|
|
|
untieColIdFromLabel: boolean;
|
|
|
|
summarySourceCol: number;
|
|
|
|
displayCol: number;
|
|
|
|
visibleCol: number;
|
2022-03-22 13:41:11 +00:00
|
|
|
rules: [GristObjCode.List, ...number[]]|null;
|
(core) Adding backend for 2-way references
Summary:
Adding support for 2-way references in data engine.
- Columns have an `reverseCol` field, which says "this is a reverse of the given column, update me when that one changes".
- At the time of setting `reverseCol`, we ensure that it's symmetrical to make a 2-way reference.
- Elsewhere we just implement syncing in one direction:
- When `reverseCol` is present, user code is generated with a type like `grist.ReferenceList("Tasks", reverse_of="Assignee")`
- On updating a ref column, we use `prepare_new_values()` method to generate corresponding updates to any column that's a reverse of it.
- The `prepare_new_values()` approach is extended to support this.
- We don't add (or remove) any mappings between rows, and rely on existing mappings (in a ref column's `_relation`) to create reverse updates.
NOTE This is polished version of https://phab.getgrist.com/D4307 with tests and 3 bug fixes
- Column transformation didn't work when transforming RefList to Ref, the reverse column became out of sync
- Tables with reverse columns couldn't be removed
- Setting json arrays to RefList didn't work if arrays contained other things besides ints
Those fixes are covered by new tests.
Test Plan: New tests
Reviewers: georgegevoian, paulfitz, dsagal
Reviewed By: georgegevoian, paulfitz
Subscribers: dsagal
Differential Revision: https://phab.getgrist.com/D4322
2024-09-09 16:24:11 +00:00
|
|
|
reverseCol: number;
|
2021-06-29 04:47:59 +00:00
|
|
|
recalcWhen: number;
|
2021-10-07 21:02:51 +00:00
|
|
|
recalcDeps: [GristObjCode.List, ...number[]]|null;
|
2020-07-21 13:20:51 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
"_grist_Imports": {
|
|
|
|
tableRef: number;
|
|
|
|
origFileName: string;
|
|
|
|
parseFormula: string;
|
|
|
|
delimiter: string;
|
|
|
|
doublequote: boolean;
|
|
|
|
escapechar: string;
|
|
|
|
quotechar: string;
|
|
|
|
skipinitialspace: boolean;
|
|
|
|
encoding: string;
|
|
|
|
hasHeaders: boolean;
|
|
|
|
};
|
|
|
|
|
|
|
|
"_grist_External_database": {
|
|
|
|
host: string;
|
|
|
|
port: number;
|
|
|
|
username: string;
|
|
|
|
dialect: string;
|
|
|
|
database: string;
|
|
|
|
storage: string;
|
|
|
|
};
|
|
|
|
|
|
|
|
"_grist_External_table": {
|
|
|
|
tableRef: number;
|
|
|
|
databaseRef: number;
|
|
|
|
tableName: string;
|
|
|
|
};
|
|
|
|
|
|
|
|
"_grist_TableViews": {
|
|
|
|
tableRef: number;
|
|
|
|
viewRef: number;
|
|
|
|
};
|
|
|
|
|
|
|
|
"_grist_TabItems": {
|
|
|
|
tableRef: number;
|
|
|
|
viewRef: number;
|
|
|
|
};
|
|
|
|
|
|
|
|
"_grist_TabBar": {
|
|
|
|
viewRef: number;
|
|
|
|
tabPos: number;
|
|
|
|
};
|
|
|
|
|
|
|
|
"_grist_Pages": {
|
|
|
|
viewRef: number;
|
|
|
|
indentation: number;
|
|
|
|
pagePos: number;
|
(core) add initial support for special shares
Summary:
This gives a mechanism for controlling access control within a document that is distinct from (though implemented with the same machinery as) granular access rules.
It was hard to find a good way to insert this that didn't dissolve in a soup of complications, so here's what I went with:
* When reading rules, if there are shares, extra rules are added.
* If there are shares, all rules are made conditional on a "ShareRef" user property.
* "ShareRef" is null when a doc is accessed in normal way, and the row id of a share when accessed via a share.
There's no UI for controlling shares (George is working on it for forms), but you can do it by editing a `_grist_Shares` table in a document. Suppose you make a fresh document with a single page/table/widget, then to create an empty share you can do:
```
gristDocPageModel.gristDoc.get().docData.sendAction(['AddRecord', '_grist_Shares', null, {linkId: 'xyz', options: '{"publish": true}'}])
```
If you look at the home db now there should be something in the `shares` table:
```
$ sqlite3 -table landing.db "select * from shares"
+----+------------------------+------------------------+--------------+---------+
| id | key | doc_id | link_id | options |
+----+------------------------+------------------------+--------------+---------+
| 1 | gSL4g38PsyautLHnjmXh2K | 4qYuace1xP2CTcPunFdtan | xyz | ... |
+----+------------------------+------------------------+--------------+---------+
```
If you take the key from that (gSL4g38PsyautLHnjmXh2K in this case) and replace the document's urlId in its URL with `s.<key>` (in this case `s.gSL4g38PsyautLHnjmXh2K` then you can use the regular document landing page (it will be quite blank initially) or API endpoint via the share.
E.g. for me `http://localhost:8080/o/docs/s0gSL4g38PsyautLHnjmXh2K/share-inter-3` accesses the doc.
To actually share some material - useful commands:
```
gristDocPageModel.gristDoc.get().docData.getMetaTable('_grist_Views_section').getRecords()
gristDocPageModel.gristDoc.get().docData.sendAction(['UpdateRecord', '_grist_Views_section', 1, {shareOptions: '{"publish": true, "form": true}'}])
gristDocPageModel.gristDoc.get().docData.getMetaTable('_grist_Pages').getRecords()
gristDocPageModel.gristDoc.get().docData.sendAction(['UpdateRecord', '_grist_Pages', 1, {shareRef: 1}])
```
For a share to be effective, at least one page needs to have its shareRef set to the rowId of the share, and at least one widget on one of those pages needs to have its shareOptions set to {"publish": "true", "form": "true"} (meaning turn on sharing, and include form sharing), and the share itself needs {"publish": true} on its options.
I think special shares are kind of incompatible with public sharing, since by their nature (allowing access to all endpoints) they easily expose the docId, and changing that would be hard.
Test Plan: tests added
Reviewers: dsagal, georgegevoian
Reviewed By: dsagal, georgegevoian
Subscribers: jarek, dsagal
Differential Revision: https://phab.getgrist.com/D4144
2024-01-03 16:53:20 +00:00
|
|
|
shareRef: number;
|
2020-07-21 13:20:51 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
"_grist_Views": {
|
|
|
|
name: string;
|
|
|
|
type: string;
|
|
|
|
layoutSpec: string;
|
|
|
|
};
|
|
|
|
|
|
|
|
"_grist_Views_section": {
|
|
|
|
tableRef: number;
|
|
|
|
parentId: number;
|
|
|
|
parentKey: string;
|
|
|
|
title: string;
|
2023-05-15 15:16:58 +00:00
|
|
|
description: string;
|
2020-07-21 13:20:51 +00:00
|
|
|
defaultWidth: number;
|
|
|
|
borderWidth: number;
|
|
|
|
theme: string;
|
|
|
|
options: string;
|
|
|
|
chartType: string;
|
|
|
|
layoutSpec: string;
|
|
|
|
filterSpec: string;
|
|
|
|
sortColRefs: string;
|
|
|
|
linkSrcSectionRef: number;
|
|
|
|
linkSrcColRef: number;
|
|
|
|
linkTargetColRef: number;
|
|
|
|
embedId: string;
|
2022-08-08 13:32:50 +00:00
|
|
|
rules: [GristObjCode.List, ...number[]]|null;
|
(core) add initial support for special shares
Summary:
This gives a mechanism for controlling access control within a document that is distinct from (though implemented with the same machinery as) granular access rules.
It was hard to find a good way to insert this that didn't dissolve in a soup of complications, so here's what I went with:
* When reading rules, if there are shares, extra rules are added.
* If there are shares, all rules are made conditional on a "ShareRef" user property.
* "ShareRef" is null when a doc is accessed in normal way, and the row id of a share when accessed via a share.
There's no UI for controlling shares (George is working on it for forms), but you can do it by editing a `_grist_Shares` table in a document. Suppose you make a fresh document with a single page/table/widget, then to create an empty share you can do:
```
gristDocPageModel.gristDoc.get().docData.sendAction(['AddRecord', '_grist_Shares', null, {linkId: 'xyz', options: '{"publish": true}'}])
```
If you look at the home db now there should be something in the `shares` table:
```
$ sqlite3 -table landing.db "select * from shares"
+----+------------------------+------------------------+--------------+---------+
| id | key | doc_id | link_id | options |
+----+------------------------+------------------------+--------------+---------+
| 1 | gSL4g38PsyautLHnjmXh2K | 4qYuace1xP2CTcPunFdtan | xyz | ... |
+----+------------------------+------------------------+--------------+---------+
```
If you take the key from that (gSL4g38PsyautLHnjmXh2K in this case) and replace the document's urlId in its URL with `s.<key>` (in this case `s.gSL4g38PsyautLHnjmXh2K` then you can use the regular document landing page (it will be quite blank initially) or API endpoint via the share.
E.g. for me `http://localhost:8080/o/docs/s0gSL4g38PsyautLHnjmXh2K/share-inter-3` accesses the doc.
To actually share some material - useful commands:
```
gristDocPageModel.gristDoc.get().docData.getMetaTable('_grist_Views_section').getRecords()
gristDocPageModel.gristDoc.get().docData.sendAction(['UpdateRecord', '_grist_Views_section', 1, {shareOptions: '{"publish": true, "form": true}'}])
gristDocPageModel.gristDoc.get().docData.getMetaTable('_grist_Pages').getRecords()
gristDocPageModel.gristDoc.get().docData.sendAction(['UpdateRecord', '_grist_Pages', 1, {shareRef: 1}])
```
For a share to be effective, at least one page needs to have its shareRef set to the rowId of the share, and at least one widget on one of those pages needs to have its shareOptions set to {"publish": "true", "form": "true"} (meaning turn on sharing, and include form sharing), and the share itself needs {"publish": true} on its options.
I think special shares are kind of incompatible with public sharing, since by their nature (allowing access to all endpoints) they easily expose the docId, and changing that would be hard.
Test Plan: tests added
Reviewers: dsagal, georgegevoian
Reviewed By: dsagal, georgegevoian
Subscribers: jarek, dsagal
Differential Revision: https://phab.getgrist.com/D4144
2024-01-03 16:53:20 +00:00
|
|
|
shareOptions: string;
|
2020-07-21 13:20:51 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
"_grist_Views_section_field": {
|
|
|
|
parentId: number;
|
|
|
|
parentPos: number;
|
|
|
|
colRef: number;
|
|
|
|
width: number;
|
|
|
|
widgetOptions: string;
|
|
|
|
displayCol: number;
|
|
|
|
visibleCol: number;
|
|
|
|
filter: string;
|
2022-03-22 13:41:11 +00:00
|
|
|
rules: [GristObjCode.List, ...number[]]|null;
|
2020-07-21 13:20:51 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
"_grist_Validations": {
|
|
|
|
formula: string;
|
|
|
|
name: string;
|
|
|
|
tableRef: number;
|
|
|
|
};
|
|
|
|
|
|
|
|
"_grist_REPL_Hist": {
|
|
|
|
code: string;
|
|
|
|
outputText: string;
|
|
|
|
errorText: string;
|
|
|
|
};
|
|
|
|
|
|
|
|
"_grist_Attachments": {
|
|
|
|
fileIdent: string;
|
|
|
|
fileName: string;
|
|
|
|
fileType: string;
|
|
|
|
fileSize: number;
|
2023-04-06 15:10:29 +00:00
|
|
|
fileExt: string;
|
2020-07-21 13:20:51 +00:00
|
|
|
imageHeight: number;
|
|
|
|
imageWidth: number;
|
2022-04-01 21:55:59 +00:00
|
|
|
timeDeleted: number;
|
2020-07-21 13:20:51 +00:00
|
|
|
timeUploaded: number;
|
|
|
|
};
|
|
|
|
|
(core) Initial webhooks implementation
Summary:
See https://grist.quip.com/VKd3ASF99ezD/Outgoing-Webhooks
- 2 new DocApi endpoints: _subscribe and _unsubscribe, not meant to be user friendly or publicly documented. _unsubscribe should be given the response from _subscribe in the body, e.g:
```
$ curl -X POST -H "Authorization: Bearer 8fd4dc59ecb05ab29ae5a183c03101319b8e6ca9" "http://localhost:8080/api/docs/6WYa23FqWxGNe3AR6DLjCJ/tables/Table2/_subscribe" -H "Content-type: application/json" -d '{"url": "https://webhook.site/a916b526-8afc-46e6-aa8f-a625d0d83ec3", "eventTypes": ["add"], "isReadyColumn": "C"}'
{"unsubscribeKey":"3246f158-55b5-4fc7-baa5-093b75ffa86c","triggerId":2,"webhookId":"853b4bfa-9d39-4639-aa33-7d45354903c0"}
$ curl -X POST -H "Authorization: Bearer 8fd4dc59ecb05ab29ae5a183c03101319b8e6ca9" "http://localhost:8080/api/docs/6WYa23FqWxGNe3AR6DLjCJ/tables/Table2/_unsubscribe" -H "Content-type: application/json" -d '{"unsubscribeKey":"3246f158-55b5-4fc7-baa5-093b75ffa86c","triggerId":2,"webhookId":"853b4bfa-9d39-4639-aa33-7d45354903c0"}'
{"success":true}
```
- New DB entity Secret to hold the webhook URL and unsubscribe key
- New document metatable _grist_Triggers subscribes to table changes and points to a secret to use for a webhook
- New file Triggers.ts processes action summaries and uses the two new tables to send webhooks.
- Also went on a bit of a diversion and made a typesafe subclass of TableData for metatables.
I think this is essentially good enough for a first diff, to keep the diffs manageable and to talk about the overall structure. Future diffs can add tests and more robustness using redis etc. After this diff I can also start building the Zapier integration privately.
Test Plan: Tested manually: see curl commands in summary for an example. Payloads can be seen in https://webhook.site/#!/a916b526-8afc-46e6-aa8f-a625d0d83ec3/0b9fe335-33f7-49fe-b90b-2db5ba53382d/1 . Great site for testing webhooks btw.
Reviewers: dsagal, paulfitz
Reviewed By: paulfitz
Differential Revision: https://phab.getgrist.com/D3019
2021-09-22 23:06:23 +00:00
|
|
|
"_grist_Triggers": {
|
|
|
|
tableRef: number;
|
2021-10-07 21:02:51 +00:00
|
|
|
eventTypes: [GristObjCode.List, ...string[]]|null;
|
(core) Initial webhooks implementation
Summary:
See https://grist.quip.com/VKd3ASF99ezD/Outgoing-Webhooks
- 2 new DocApi endpoints: _subscribe and _unsubscribe, not meant to be user friendly or publicly documented. _unsubscribe should be given the response from _subscribe in the body, e.g:
```
$ curl -X POST -H "Authorization: Bearer 8fd4dc59ecb05ab29ae5a183c03101319b8e6ca9" "http://localhost:8080/api/docs/6WYa23FqWxGNe3AR6DLjCJ/tables/Table2/_subscribe" -H "Content-type: application/json" -d '{"url": "https://webhook.site/a916b526-8afc-46e6-aa8f-a625d0d83ec3", "eventTypes": ["add"], "isReadyColumn": "C"}'
{"unsubscribeKey":"3246f158-55b5-4fc7-baa5-093b75ffa86c","triggerId":2,"webhookId":"853b4bfa-9d39-4639-aa33-7d45354903c0"}
$ curl -X POST -H "Authorization: Bearer 8fd4dc59ecb05ab29ae5a183c03101319b8e6ca9" "http://localhost:8080/api/docs/6WYa23FqWxGNe3AR6DLjCJ/tables/Table2/_unsubscribe" -H "Content-type: application/json" -d '{"unsubscribeKey":"3246f158-55b5-4fc7-baa5-093b75ffa86c","triggerId":2,"webhookId":"853b4bfa-9d39-4639-aa33-7d45354903c0"}'
{"success":true}
```
- New DB entity Secret to hold the webhook URL and unsubscribe key
- New document metatable _grist_Triggers subscribes to table changes and points to a secret to use for a webhook
- New file Triggers.ts processes action summaries and uses the two new tables to send webhooks.
- Also went on a bit of a diversion and made a typesafe subclass of TableData for metatables.
I think this is essentially good enough for a first diff, to keep the diffs manageable and to talk about the overall structure. Future diffs can add tests and more robustness using redis etc. After this diff I can also start building the Zapier integration privately.
Test Plan: Tested manually: see curl commands in summary for an example. Payloads can be seen in https://webhook.site/#!/a916b526-8afc-46e6-aa8f-a625d0d83ec3/0b9fe335-33f7-49fe-b90b-2db5ba53382d/1 . Great site for testing webhooks btw.
Reviewers: dsagal, paulfitz
Reviewed By: paulfitz
Differential Revision: https://phab.getgrist.com/D3019
2021-09-22 23:06:23 +00:00
|
|
|
isReadyColRef: number;
|
|
|
|
actions: string;
|
2023-05-08 22:06:24 +00:00
|
|
|
label: string;
|
|
|
|
memo: string;
|
|
|
|
enabled: boolean;
|
2024-04-12 20:04:37 +00:00
|
|
|
watchedColRefList: [GristObjCode.List, ...number[]]|null;
|
|
|
|
options: string;
|
(core) Initial webhooks implementation
Summary:
See https://grist.quip.com/VKd3ASF99ezD/Outgoing-Webhooks
- 2 new DocApi endpoints: _subscribe and _unsubscribe, not meant to be user friendly or publicly documented. _unsubscribe should be given the response from _subscribe in the body, e.g:
```
$ curl -X POST -H "Authorization: Bearer 8fd4dc59ecb05ab29ae5a183c03101319b8e6ca9" "http://localhost:8080/api/docs/6WYa23FqWxGNe3AR6DLjCJ/tables/Table2/_subscribe" -H "Content-type: application/json" -d '{"url": "https://webhook.site/a916b526-8afc-46e6-aa8f-a625d0d83ec3", "eventTypes": ["add"], "isReadyColumn": "C"}'
{"unsubscribeKey":"3246f158-55b5-4fc7-baa5-093b75ffa86c","triggerId":2,"webhookId":"853b4bfa-9d39-4639-aa33-7d45354903c0"}
$ curl -X POST -H "Authorization: Bearer 8fd4dc59ecb05ab29ae5a183c03101319b8e6ca9" "http://localhost:8080/api/docs/6WYa23FqWxGNe3AR6DLjCJ/tables/Table2/_unsubscribe" -H "Content-type: application/json" -d '{"unsubscribeKey":"3246f158-55b5-4fc7-baa5-093b75ffa86c","triggerId":2,"webhookId":"853b4bfa-9d39-4639-aa33-7d45354903c0"}'
{"success":true}
```
- New DB entity Secret to hold the webhook URL and unsubscribe key
- New document metatable _grist_Triggers subscribes to table changes and points to a secret to use for a webhook
- New file Triggers.ts processes action summaries and uses the two new tables to send webhooks.
- Also went on a bit of a diversion and made a typesafe subclass of TableData for metatables.
I think this is essentially good enough for a first diff, to keep the diffs manageable and to talk about the overall structure. Future diffs can add tests and more robustness using redis etc. After this diff I can also start building the Zapier integration privately.
Test Plan: Tested manually: see curl commands in summary for an example. Payloads can be seen in https://webhook.site/#!/a916b526-8afc-46e6-aa8f-a625d0d83ec3/0b9fe335-33f7-49fe-b90b-2db5ba53382d/1 . Great site for testing webhooks btw.
Reviewers: dsagal, paulfitz
Reviewed By: paulfitz
Differential Revision: https://phab.getgrist.com/D3019
2021-09-22 23:06:23 +00:00
|
|
|
};
|
|
|
|
|
2020-07-21 13:20:51 +00:00
|
|
|
"_grist_ACLRules": {
|
|
|
|
resource: number;
|
|
|
|
permissions: number;
|
|
|
|
principals: string;
|
|
|
|
aclFormula: string;
|
|
|
|
aclColumn: number;
|
2020-11-17 21:49:32 +00:00
|
|
|
aclFormulaParsed: string;
|
|
|
|
permissionsText: string;
|
|
|
|
rulePos: number;
|
|
|
|
userAttributes: string;
|
2022-12-12 06:29:20 +00:00
|
|
|
memo: string;
|
2020-07-21 13:20:51 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
"_grist_ACLResources": {
|
|
|
|
tableId: string;
|
|
|
|
colIds: string;
|
|
|
|
};
|
|
|
|
|
|
|
|
"_grist_ACLPrincipals": {
|
|
|
|
type: string;
|
|
|
|
userEmail: string;
|
|
|
|
userName: string;
|
|
|
|
groupName: string;
|
|
|
|
instanceId: string;
|
|
|
|
};
|
|
|
|
|
|
|
|
"_grist_ACLMemberships": {
|
|
|
|
parent: number;
|
|
|
|
child: number;
|
|
|
|
};
|
|
|
|
|
2021-11-19 20:30:11 +00:00
|
|
|
"_grist_Filters": {
|
|
|
|
viewSectionRef: number;
|
|
|
|
colRef: number;
|
|
|
|
filter: string;
|
2022-11-17 20:17:51 +00:00
|
|
|
pinned: boolean;
|
2021-11-19 20:30:11 +00:00
|
|
|
};
|
|
|
|
|
2022-10-17 09:47:16 +00:00
|
|
|
"_grist_Cells": {
|
|
|
|
tableRef: number;
|
|
|
|
colRef: number;
|
|
|
|
rowId: number;
|
|
|
|
root: boolean;
|
|
|
|
parentId: number;
|
|
|
|
type: number;
|
|
|
|
content: string;
|
|
|
|
userRef: string;
|
|
|
|
};
|
|
|
|
|
(core) add initial support for special shares
Summary:
This gives a mechanism for controlling access control within a document that is distinct from (though implemented with the same machinery as) granular access rules.
It was hard to find a good way to insert this that didn't dissolve in a soup of complications, so here's what I went with:
* When reading rules, if there are shares, extra rules are added.
* If there are shares, all rules are made conditional on a "ShareRef" user property.
* "ShareRef" is null when a doc is accessed in normal way, and the row id of a share when accessed via a share.
There's no UI for controlling shares (George is working on it for forms), but you can do it by editing a `_grist_Shares` table in a document. Suppose you make a fresh document with a single page/table/widget, then to create an empty share you can do:
```
gristDocPageModel.gristDoc.get().docData.sendAction(['AddRecord', '_grist_Shares', null, {linkId: 'xyz', options: '{"publish": true}'}])
```
If you look at the home db now there should be something in the `shares` table:
```
$ sqlite3 -table landing.db "select * from shares"
+----+------------------------+------------------------+--------------+---------+
| id | key | doc_id | link_id | options |
+----+------------------------+------------------------+--------------+---------+
| 1 | gSL4g38PsyautLHnjmXh2K | 4qYuace1xP2CTcPunFdtan | xyz | ... |
+----+------------------------+------------------------+--------------+---------+
```
If you take the key from that (gSL4g38PsyautLHnjmXh2K in this case) and replace the document's urlId in its URL with `s.<key>` (in this case `s.gSL4g38PsyautLHnjmXh2K` then you can use the regular document landing page (it will be quite blank initially) or API endpoint via the share.
E.g. for me `http://localhost:8080/o/docs/s0gSL4g38PsyautLHnjmXh2K/share-inter-3` accesses the doc.
To actually share some material - useful commands:
```
gristDocPageModel.gristDoc.get().docData.getMetaTable('_grist_Views_section').getRecords()
gristDocPageModel.gristDoc.get().docData.sendAction(['UpdateRecord', '_grist_Views_section', 1, {shareOptions: '{"publish": true, "form": true}'}])
gristDocPageModel.gristDoc.get().docData.getMetaTable('_grist_Pages').getRecords()
gristDocPageModel.gristDoc.get().docData.sendAction(['UpdateRecord', '_grist_Pages', 1, {shareRef: 1}])
```
For a share to be effective, at least one page needs to have its shareRef set to the rowId of the share, and at least one widget on one of those pages needs to have its shareOptions set to {"publish": "true", "form": "true"} (meaning turn on sharing, and include form sharing), and the share itself needs {"publish": true} on its options.
I think special shares are kind of incompatible with public sharing, since by their nature (allowing access to all endpoints) they easily expose the docId, and changing that would be hard.
Test Plan: tests added
Reviewers: dsagal, georgegevoian
Reviewed By: dsagal, georgegevoian
Subscribers: jarek, dsagal
Differential Revision: https://phab.getgrist.com/D4144
2024-01-03 16:53:20 +00:00
|
|
|
"_grist_Shares": {
|
|
|
|
linkId: string;
|
|
|
|
options: string;
|
|
|
|
label: string;
|
|
|
|
description: string;
|
|
|
|
};
|
|
|
|
|
2020-07-21 13:20:51 +00:00
|
|
|
}
|