2023-06-06 17:08:50 +00:00
|
|
|
import { GristDeploymentType, GristLoadConfig } from 'app/common/gristUrls';
|
2023-10-18 14:31:58 +00:00
|
|
|
import { UserProfile } from 'app/common/UserAPI';
|
2021-03-18 22:40:02 +00:00
|
|
|
import { Document } from 'app/gen-server/entity/Document';
|
|
|
|
import { Organization } from 'app/gen-server/entity/Organization';
|
2023-10-18 14:31:58 +00:00
|
|
|
import { User } from 'app/gen-server/entity/User';
|
2021-03-18 22:40:02 +00:00
|
|
|
import { Workspace } from 'app/gen-server/entity/Workspace';
|
2023-06-06 17:08:50 +00:00
|
|
|
import { Activations } from 'app/gen-server/lib/Activations';
|
2021-08-17 15:22:30 +00:00
|
|
|
import { HomeDBManager } from 'app/gen-server/lib/HomeDBManager';
|
2022-07-19 15:39:49 +00:00
|
|
|
import { IAccessTokens } from 'app/server/lib/AccessTokens';
|
2022-02-11 06:03:30 +00:00
|
|
|
import { RequestWithLogin } from 'app/server/lib/Authorizer';
|
2022-06-04 04:12:30 +00:00
|
|
|
import { Comm } from 'app/server/lib/Comm';
|
(core) add a `yarn run cli` tool, and add a `sqlite gristify` option
Summary:
This adds rudimentary support for opening certain SQLite files in Grist.
If you have a file such as `landing.db` in Grist, you can convert it to Grist format by doing (either in monorepo or grist-core):
```
yarn run cli -h
yarn run cli sqlite -h
yarn run cli sqlite gristify landing.db
```
The file is now openable by Grist. To actually do so with the regular Grist server, you'll need to either import it, or convert some doc you don't care about in the `samples/` directory to be a soft link to it (and then force a reload).
This implementation is a rudimentary experiment. Here are some awkwardnesses:
* Only tables that happen to have a column called `id`, and where the column happens to be an integer, can be opened directly with Grist as it is today. That could be generalized, but it looked more than a Gristathon's worth of work, so I instead used SQLite views.
* Grist will handle tables that start with an uncapitalized letter a bit erratically. You can successfully add columns, for example, but removing them will cause sadness - Grist will rename the table in a confused way.
* I didn't attempt to deal with column names with spaces etc (though views could deal with those).
* I haven't tried to do any fancy type mapping.
* Columns with constraints can make adding new rows impossible in Grist, since Grist requires that a row can be added with just a single cell set.
Test Plan: added small test
Reviewers: georgegevoian
Reviewed By: georgegevoian
Differential Revision: https://phab.getgrist.com/D3502
2022-07-14 09:32:06 +00:00
|
|
|
import { create } from 'app/server/lib/create';
|
2021-03-18 22:40:02 +00:00
|
|
|
import { Hosts } from 'app/server/lib/extractOrg';
|
|
|
|
import { ICreate } from 'app/server/lib/ICreate';
|
2021-09-13 21:29:35 +00:00
|
|
|
import { IDocStorageManager } from 'app/server/lib/IDocStorageManager';
|
2022-02-24 00:27:16 +00:00
|
|
|
import { INotifier } from 'app/server/lib/INotifier';
|
2021-03-18 22:40:02 +00:00
|
|
|
import { IPermitStore } from 'app/server/lib/Permit';
|
2022-03-07 16:40:46 +00:00
|
|
|
import { ISendAppPageOptions } from 'app/server/lib/sendAppPage';
|
2022-04-04 21:50:40 +00:00
|
|
|
import { fromCallback } from 'app/server/lib/serverUtils';
|
2021-03-18 22:40:02 +00:00
|
|
|
import { Sessions } from 'app/server/lib/Sessions';
|
2023-06-06 17:08:50 +00:00
|
|
|
import { ITelemetry } from 'app/server/lib/Telemetry';
|
2020-07-21 13:20:51 +00:00
|
|
|
import * as express from 'express';
|
2022-06-15 14:29:29 +00:00
|
|
|
import { IncomingMessage } from 'http';
|
2020-07-21 13:20:51 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Basic information about a Grist server. Accessible in many
|
|
|
|
* contexts, including request handlers and ActiveDoc methods.
|
|
|
|
*/
|
|
|
|
export interface GristServer {
|
|
|
|
readonly create: ICreate;
|
2022-05-17 22:25:36 +00:00
|
|
|
settings?: Readonly<Record<string, unknown>>;
|
2020-07-21 13:20:51 +00:00
|
|
|
getHost(): string;
|
|
|
|
getHomeUrl(req: express.Request, relPath?: string): string;
|
|
|
|
getHomeUrlByDocId(docId: string, relPath?: string): Promise<string>;
|
(core) make Grist easier to run with a single server
Summary:
This makes many small changes so that Grist is less fussy to run as a single instance behind a reverse proxy. Some users had difficulty with the self-connections Grist would make, due to internal network setup, and since these are unnecessary in any case in this scenario, they are now optimized away. Likewise some users had difficulties related to doc worker urls, which are now also optimized away. With these changes, users should be able to get a lot further on first try, at least far enough to open and edit documents.
The `GRIST_SINGLE_ORG` setting was proving a bit confusing, since it appeared to only work when set to `docs`. This diff
adds a check for whether the specified org exists, and if not, it creates it. This still depends on having a user email to make as the owner of the team, so there could be remaining difficulties there.
Test Plan: tested manually with nginx
Reviewers: jarek
Reviewed By: jarek
Differential Revision: https://phab.getgrist.com/D3299
2022-03-02 19:07:26 +00:00
|
|
|
getOwnUrl(): string;
|
2021-06-17 20:48:46 +00:00
|
|
|
getOrgUrl(orgKey: string|number): Promise<string>;
|
2022-02-11 06:03:30 +00:00
|
|
|
getMergedOrgUrl(req: RequestWithLogin, pathname?: string): string;
|
2022-07-19 15:39:49 +00:00
|
|
|
getResourceUrl(resource: Organization|Workspace|Document,
|
|
|
|
purpose?: 'api'|'html'): Promise<string>;
|
2021-03-18 22:40:02 +00:00
|
|
|
getGristConfig(): GristLoadConfig;
|
2021-01-12 15:48:40 +00:00
|
|
|
getPermitStore(): IPermitStore;
|
2021-08-16 15:11:17 +00:00
|
|
|
getExternalPermitStore(): IPermitStore;
|
|
|
|
getSessions(): Sessions;
|
2021-08-17 15:22:30 +00:00
|
|
|
getComm(): Comm;
|
2023-06-06 17:08:50 +00:00
|
|
|
getDeploymentType(): GristDeploymentType;
|
2021-08-17 15:22:30 +00:00
|
|
|
getHosts(): Hosts;
|
2023-06-06 17:08:50 +00:00
|
|
|
getActivations(): Activations;
|
2021-08-17 15:22:30 +00:00
|
|
|
getHomeDBManager(): HomeDBManager;
|
2021-09-13 21:29:35 +00:00
|
|
|
getStorageManager(): IDocStorageManager;
|
2023-06-06 17:08:50 +00:00
|
|
|
getTelemetry(): ITelemetry;
|
2022-02-24 00:27:16 +00:00
|
|
|
getNotifier(): INotifier;
|
(core) make Grist easier to run with a single server
Summary:
This makes many small changes so that Grist is less fussy to run as a single instance behind a reverse proxy. Some users had difficulty with the self-connections Grist would make, due to internal network setup, and since these are unnecessary in any case in this scenario, they are now optimized away. Likewise some users had difficulties related to doc worker urls, which are now also optimized away. With these changes, users should be able to get a lot further on first try, at least far enough to open and edit documents.
The `GRIST_SINGLE_ORG` setting was proving a bit confusing, since it appeared to only work when set to `docs`. This diff
adds a check for whether the specified org exists, and if not, it creates it. This still depends on having a user email to make as the owner of the team, so there could be remaining difficulties there.
Test Plan: tested manually with nginx
Reviewers: jarek
Reviewed By: jarek
Differential Revision: https://phab.getgrist.com/D3299
2022-03-02 19:07:26 +00:00
|
|
|
getDocTemplate(): Promise<DocTemplate>;
|
|
|
|
getTag(): string;
|
2022-03-07 16:40:46 +00:00
|
|
|
sendAppPage(req: express.Request, resp: express.Response, options: ISendAppPageOptions): Promise<void>;
|
2022-07-19 15:39:49 +00:00
|
|
|
getAccessTokens(): IAccessTokens;
|
2023-09-26 08:09:06 +00:00
|
|
|
resolveLoginSystem(): Promise<GristLoginSystem>;
|
2020-07-21 13:20:51 +00:00
|
|
|
}
|
|
|
|
|
2021-09-29 15:39:56 +00:00
|
|
|
export interface GristLoginSystem {
|
|
|
|
getMiddleware(gristServer: GristServer): Promise<GristLoginMiddleware>;
|
2023-10-18 14:31:58 +00:00
|
|
|
deleteUser(user: User): Promise<void>;
|
2021-09-29 15:39:56 +00:00
|
|
|
}
|
|
|
|
|
2020-07-21 13:20:51 +00:00
|
|
|
export interface GristLoginMiddleware {
|
2021-08-16 15:11:17 +00:00
|
|
|
getLoginRedirectUrl(req: express.Request, target: URL): Promise<string>;
|
|
|
|
getSignUpRedirectUrl(req: express.Request, target: URL): Promise<string>;
|
|
|
|
getLogoutRedirectUrl(req: express.Request, nextUrl: URL): Promise<string>;
|
2022-03-07 16:40:46 +00:00
|
|
|
// Optional middleware for the GET /login, /signup, and /signin routes.
|
|
|
|
getLoginOrSignUpMiddleware?(): express.RequestHandler[];
|
2022-04-01 21:31:24 +00:00
|
|
|
// Optional middleware for the GET /logout route.
|
|
|
|
getLogoutMiddleware?(): express.RequestHandler[];
|
2023-02-13 20:52:17 +00:00
|
|
|
// Optional middleware for all routes.
|
|
|
|
getWildcardMiddleware?(): express.RequestHandler[];
|
2020-07-21 13:20:51 +00:00
|
|
|
// Returns arbitrary string for log.
|
2021-08-17 15:22:30 +00:00
|
|
|
addEndpoints(app: express.Express): Promise<string>;
|
2022-06-15 14:29:29 +00:00
|
|
|
// Optionally, extract profile from request. Result can be a profile,
|
|
|
|
// or null if anonymous (and other methods of determining profile such
|
|
|
|
// as a cookie should not be used), or undefined to use other methods.
|
|
|
|
getProfile?(req: express.Request|IncomingMessage): Promise<UserProfile|null|undefined>;
|
2023-06-15 00:03:17 +00:00
|
|
|
// Called on first visit to an app page after a signup, for reporting or telemetry purposes.
|
|
|
|
onFirstVisit?(req: express.Request): void;
|
2020-07-21 13:20:51 +00:00
|
|
|
}
|
(core) move more tests to grist-core
Summary:
* Tie build and run-time docker base images to a consistent version (buster)
* Extend the test login system activated by GRIST_TEST_LOGIN to ease porting tests that currently rely on cognito (many)
* Make org resets work in absence of billing endpoints
* When in-memory session caches are used, add missing invalidation steps
* Pass org information through sign-ups/sign-ins more carefully
* For CORS, explicitly trust GRIST_HOST origin when set
* Move some fixtures and tests to core, focussing on tests that cover existing failures or are in the set of tests run on deployments
* Retain regular `test` target to run the test suite directly, without docker
* Add a `test:smoke` target to run a single simple test without `GRIST_TEST_LOGIN` activated
* Add a `test:docker` target to run the tests against a grist-core docker image - since tests rely on certain fixture teams/docs, added `TEST_SUPPORT_API_KEY` and `TEST_ADD_SAMPLES` flags to ease porting
The tests ported were `nbrowser` tests: `ActionLog.ts` (the first test I tend to port to anything, out of habit), `Fork.ts` (exercises a lot of doc creation paths), `HomeIntro.ts` (a lot of DocMenu exercise), and `DuplicateDocument.ts` (covers a feature known to be failing prior to this diff, the CORS tweak resolves it).
Test Plan: Manually tested via `buildtools/build_core.sh`. In follow up, I want to add running the `test:docker` target in grist-core's workflows. In jenkins, only the smoke test is run. There'd be an argument for running all tests, but they include particularly slow tests, and are duplicates of tests already run (in different configuration admittedly), so I'd like to try first just using them in grist-core to gate updates to any packaged version of Grist (the docker image currently).
Reviewers: alexmojaki
Reviewed By: alexmojaki
Subscribers: alexmojaki
Differential Revision: https://phab.getgrist.com/D3176
2021-12-10 22:42:54 +00:00
|
|
|
|
2022-04-04 21:50:40 +00:00
|
|
|
/**
|
|
|
|
* Set the user in the current session.
|
|
|
|
*/
|
|
|
|
export async function setUserInSession(req: express.Request, gristServer: GristServer, profile: UserProfile) {
|
|
|
|
const scopedSession = gristServer.getSessions().getOrCreateSessionFromRequest(req);
|
|
|
|
// Make sure session is up to date before operating on it.
|
|
|
|
// Behavior on a completely fresh session is a little awkward currently.
|
|
|
|
const reqSession = (req as any).session;
|
|
|
|
if (reqSession?.save) {
|
|
|
|
await fromCallback(cb => reqSession.save(cb));
|
|
|
|
}
|
|
|
|
await scopedSession.updateUserProfile(req, profile);
|
|
|
|
}
|
|
|
|
|
(core) move more tests to grist-core
Summary:
* Tie build and run-time docker base images to a consistent version (buster)
* Extend the test login system activated by GRIST_TEST_LOGIN to ease porting tests that currently rely on cognito (many)
* Make org resets work in absence of billing endpoints
* When in-memory session caches are used, add missing invalidation steps
* Pass org information through sign-ups/sign-ins more carefully
* For CORS, explicitly trust GRIST_HOST origin when set
* Move some fixtures and tests to core, focussing on tests that cover existing failures or are in the set of tests run on deployments
* Retain regular `test` target to run the test suite directly, without docker
* Add a `test:smoke` target to run a single simple test without `GRIST_TEST_LOGIN` activated
* Add a `test:docker` target to run the tests against a grist-core docker image - since tests rely on certain fixture teams/docs, added `TEST_SUPPORT_API_KEY` and `TEST_ADD_SAMPLES` flags to ease porting
The tests ported were `nbrowser` tests: `ActionLog.ts` (the first test I tend to port to anything, out of habit), `Fork.ts` (exercises a lot of doc creation paths), `HomeIntro.ts` (a lot of DocMenu exercise), and `DuplicateDocument.ts` (covers a feature known to be failing prior to this diff, the CORS tweak resolves it).
Test Plan: Manually tested via `buildtools/build_core.sh`. In follow up, I want to add running the `test:docker` target in grist-core's workflows. In jenkins, only the smoke test is run. There'd be an argument for running all tests, but they include particularly slow tests, and are duplicates of tests already run (in different configuration admittedly), so I'd like to try first just using them in grist-core to gate updates to any packaged version of Grist (the docker image currently).
Reviewers: alexmojaki
Reviewed By: alexmojaki
Subscribers: alexmojaki
Differential Revision: https://phab.getgrist.com/D3176
2021-12-10 22:42:54 +00:00
|
|
|
export interface RequestWithGrist extends express.Request {
|
|
|
|
gristServer?: GristServer;
|
|
|
|
}
|
(core) make Grist easier to run with a single server
Summary:
This makes many small changes so that Grist is less fussy to run as a single instance behind a reverse proxy. Some users had difficulty with the self-connections Grist would make, due to internal network setup, and since these are unnecessary in any case in this scenario, they are now optimized away. Likewise some users had difficulties related to doc worker urls, which are now also optimized away. With these changes, users should be able to get a lot further on first try, at least far enough to open and edit documents.
The `GRIST_SINGLE_ORG` setting was proving a bit confusing, since it appeared to only work when set to `docs`. This diff
adds a check for whether the specified org exists, and if not, it creates it. This still depends on having a user email to make as the owner of the team, so there could be remaining difficulties there.
Test Plan: tested manually with nginx
Reviewers: jarek
Reviewed By: jarek
Differential Revision: https://phab.getgrist.com/D3299
2022-03-02 19:07:26 +00:00
|
|
|
|
|
|
|
export interface DocTemplate {
|
|
|
|
page: string,
|
|
|
|
tag: string,
|
|
|
|
}
|
(core) add a `yarn run cli` tool, and add a `sqlite gristify` option
Summary:
This adds rudimentary support for opening certain SQLite files in Grist.
If you have a file such as `landing.db` in Grist, you can convert it to Grist format by doing (either in monorepo or grist-core):
```
yarn run cli -h
yarn run cli sqlite -h
yarn run cli sqlite gristify landing.db
```
The file is now openable by Grist. To actually do so with the regular Grist server, you'll need to either import it, or convert some doc you don't care about in the `samples/` directory to be a soft link to it (and then force a reload).
This implementation is a rudimentary experiment. Here are some awkwardnesses:
* Only tables that happen to have a column called `id`, and where the column happens to be an integer, can be opened directly with Grist as it is today. That could be generalized, but it looked more than a Gristathon's worth of work, so I instead used SQLite views.
* Grist will handle tables that start with an uncapitalized letter a bit erratically. You can successfully add columns, for example, but removing them will cause sadness - Grist will rename the table in a confused way.
* I didn't attempt to deal with column names with spaces etc (though views could deal with those).
* I haven't tried to do any fancy type mapping.
* Columns with constraints can make adding new rows impossible in Grist, since Grist requires that a row can be added with just a single cell set.
Test Plan: added small test
Reviewers: georgegevoian
Reviewed By: georgegevoian
Differential Revision: https://phab.getgrist.com/D3502
2022-07-14 09:32:06 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* A very minimal GristServer object that throws an error if its bluff is
|
|
|
|
* called.
|
|
|
|
*/
|
|
|
|
export function createDummyGristServer(): GristServer {
|
|
|
|
return {
|
|
|
|
create,
|
|
|
|
settings: {},
|
|
|
|
getHost() { return 'localhost:4242'; },
|
|
|
|
getHomeUrl() { return 'http://localhost:4242'; },
|
|
|
|
getHomeUrlByDocId() { return Promise.resolve('http://localhost:4242'); },
|
|
|
|
getMergedOrgUrl() { return 'http://localhost:4242'; },
|
|
|
|
getOwnUrl() { return 'http://localhost:4242'; },
|
|
|
|
getPermitStore() { throw new Error('no permit store'); },
|
|
|
|
getExternalPermitStore() { throw new Error('no external permit store'); },
|
|
|
|
getGristConfig() { return { homeUrl: '', timestampMs: 0 }; },
|
|
|
|
getOrgUrl() { return Promise.resolve(''); },
|
|
|
|
getResourceUrl() { return Promise.resolve(''); },
|
|
|
|
getSessions() { throw new Error('no sessions'); },
|
|
|
|
getComm() { throw new Error('no comms'); },
|
2023-06-06 17:08:50 +00:00
|
|
|
getDeploymentType() { return 'core'; },
|
(core) add a `yarn run cli` tool, and add a `sqlite gristify` option
Summary:
This adds rudimentary support for opening certain SQLite files in Grist.
If you have a file such as `landing.db` in Grist, you can convert it to Grist format by doing (either in monorepo or grist-core):
```
yarn run cli -h
yarn run cli sqlite -h
yarn run cli sqlite gristify landing.db
```
The file is now openable by Grist. To actually do so with the regular Grist server, you'll need to either import it, or convert some doc you don't care about in the `samples/` directory to be a soft link to it (and then force a reload).
This implementation is a rudimentary experiment. Here are some awkwardnesses:
* Only tables that happen to have a column called `id`, and where the column happens to be an integer, can be opened directly with Grist as it is today. That could be generalized, but it looked more than a Gristathon's worth of work, so I instead used SQLite views.
* Grist will handle tables that start with an uncapitalized letter a bit erratically. You can successfully add columns, for example, but removing them will cause sadness - Grist will rename the table in a confused way.
* I didn't attempt to deal with column names with spaces etc (though views could deal with those).
* I haven't tried to do any fancy type mapping.
* Columns with constraints can make adding new rows impossible in Grist, since Grist requires that a row can be added with just a single cell set.
Test Plan: added small test
Reviewers: georgegevoian
Reviewed By: georgegevoian
Differential Revision: https://phab.getgrist.com/D3502
2022-07-14 09:32:06 +00:00
|
|
|
getHosts() { throw new Error('no hosts'); },
|
2023-06-06 17:08:50 +00:00
|
|
|
getActivations() { throw new Error('no activations'); },
|
(core) add a `yarn run cli` tool, and add a `sqlite gristify` option
Summary:
This adds rudimentary support for opening certain SQLite files in Grist.
If you have a file such as `landing.db` in Grist, you can convert it to Grist format by doing (either in monorepo or grist-core):
```
yarn run cli -h
yarn run cli sqlite -h
yarn run cli sqlite gristify landing.db
```
The file is now openable by Grist. To actually do so with the regular Grist server, you'll need to either import it, or convert some doc you don't care about in the `samples/` directory to be a soft link to it (and then force a reload).
This implementation is a rudimentary experiment. Here are some awkwardnesses:
* Only tables that happen to have a column called `id`, and where the column happens to be an integer, can be opened directly with Grist as it is today. That could be generalized, but it looked more than a Gristathon's worth of work, so I instead used SQLite views.
* Grist will handle tables that start with an uncapitalized letter a bit erratically. You can successfully add columns, for example, but removing them will cause sadness - Grist will rename the table in a confused way.
* I didn't attempt to deal with column names with spaces etc (though views could deal with those).
* I haven't tried to do any fancy type mapping.
* Columns with constraints can make adding new rows impossible in Grist, since Grist requires that a row can be added with just a single cell set.
Test Plan: added small test
Reviewers: georgegevoian
Reviewed By: georgegevoian
Differential Revision: https://phab.getgrist.com/D3502
2022-07-14 09:32:06 +00:00
|
|
|
getHomeDBManager() { throw new Error('no db'); },
|
|
|
|
getStorageManager() { throw new Error('no storage manager'); },
|
2023-06-06 17:08:50 +00:00
|
|
|
getTelemetry() { return createDummyTelemetry(); },
|
(core) add a `yarn run cli` tool, and add a `sqlite gristify` option
Summary:
This adds rudimentary support for opening certain SQLite files in Grist.
If you have a file such as `landing.db` in Grist, you can convert it to Grist format by doing (either in monorepo or grist-core):
```
yarn run cli -h
yarn run cli sqlite -h
yarn run cli sqlite gristify landing.db
```
The file is now openable by Grist. To actually do so with the regular Grist server, you'll need to either import it, or convert some doc you don't care about in the `samples/` directory to be a soft link to it (and then force a reload).
This implementation is a rudimentary experiment. Here are some awkwardnesses:
* Only tables that happen to have a column called `id`, and where the column happens to be an integer, can be opened directly with Grist as it is today. That could be generalized, but it looked more than a Gristathon's worth of work, so I instead used SQLite views.
* Grist will handle tables that start with an uncapitalized letter a bit erratically. You can successfully add columns, for example, but removing them will cause sadness - Grist will rename the table in a confused way.
* I didn't attempt to deal with column names with spaces etc (though views could deal with those).
* I haven't tried to do any fancy type mapping.
* Columns with constraints can make adding new rows impossible in Grist, since Grist requires that a row can be added with just a single cell set.
Test Plan: added small test
Reviewers: georgegevoian
Reviewed By: georgegevoian
Differential Revision: https://phab.getgrist.com/D3502
2022-07-14 09:32:06 +00:00
|
|
|
getNotifier() { throw new Error('no notifier'); },
|
|
|
|
getDocTemplate() { throw new Error('no doc template'); },
|
|
|
|
getTag() { return 'tag'; },
|
|
|
|
sendAppPage() { return Promise.resolve(); },
|
2022-07-19 15:39:49 +00:00
|
|
|
getAccessTokens() { throw new Error('no access tokens'); },
|
2023-09-26 08:09:06 +00:00
|
|
|
resolveLoginSystem() { throw new Error('no login system'); },
|
(core) add a `yarn run cli` tool, and add a `sqlite gristify` option
Summary:
This adds rudimentary support for opening certain SQLite files in Grist.
If you have a file such as `landing.db` in Grist, you can convert it to Grist format by doing (either in monorepo or grist-core):
```
yarn run cli -h
yarn run cli sqlite -h
yarn run cli sqlite gristify landing.db
```
The file is now openable by Grist. To actually do so with the regular Grist server, you'll need to either import it, or convert some doc you don't care about in the `samples/` directory to be a soft link to it (and then force a reload).
This implementation is a rudimentary experiment. Here are some awkwardnesses:
* Only tables that happen to have a column called `id`, and where the column happens to be an integer, can be opened directly with Grist as it is today. That could be generalized, but it looked more than a Gristathon's worth of work, so I instead used SQLite views.
* Grist will handle tables that start with an uncapitalized letter a bit erratically. You can successfully add columns, for example, but removing them will cause sadness - Grist will rename the table in a confused way.
* I didn't attempt to deal with column names with spaces etc (though views could deal with those).
* I haven't tried to do any fancy type mapping.
* Columns with constraints can make adding new rows impossible in Grist, since Grist requires that a row can be added with just a single cell set.
Test Plan: added small test
Reviewers: georgegevoian
Reviewed By: georgegevoian
Differential Revision: https://phab.getgrist.com/D3502
2022-07-14 09:32:06 +00:00
|
|
|
};
|
|
|
|
}
|
2023-06-06 17:08:50 +00:00
|
|
|
|
|
|
|
export function createDummyTelemetry(): ITelemetry {
|
|
|
|
return {
|
|
|
|
addEndpoints() { /* do nothing */ },
|
2023-07-04 21:21:34 +00:00
|
|
|
addPages() { /* do nothing */ },
|
|
|
|
start() { return Promise.resolve(); },
|
|
|
|
logEvent() { return Promise.resolve(); },
|
|
|
|
getTelemetryConfig() { return undefined; },
|
|
|
|
fetchTelemetryPrefs() { return Promise.resolve(); },
|
2023-06-06 17:08:50 +00:00
|
|
|
};
|
|
|
|
}
|