Paul Fitzpatrick

There was progress on this in https://github.com/gristlabs/grist-core/pull/1336

It is unfortunate, we actually implemented this in our SaaS, but the only home for site-level configuration we have so far is our "billing" pages so it got put there....

> @paulfitz after a first review with @fflorent It appears that the main doubt about the actual implementation is the following. Before getting into review of this implementation, or reading...

@hexaltation thanks for the proposal write-up. Some questions: * What is the proposed access control situation for the document api key. In other words, for all operations on the key,...

> The document will take the identity of a new special user Can you tell me more about this new special user? For example, how are the properties of this...

@hexaltation can you tell me more about the following properties of the special user: * What is their `Email` * What is their `UserID`, how is that decided, is it...

> We plan to use the already existing method `initializeSpecialIds` in [`app/gen-server/lib/homedb/UsersManager.ts` ](https://github.com/gristlabs/grist-core/blob/7fcd740f111ba21a788b0564e068ba03b654605e/app/gen-server/lib/homedb/UsersManager.ts#L592) > > > ``` > > * What is their `Email` > > ``` > > `DOCAPIKEY_MAIL`...

I think it would be fine for @hexaltation to add a step that gracefully ends the workflow early if a variable needed later is missing. The only downside I see...

> Oh, I was under the assumption that the history was stored inside the actual document SQLite DB and not the `grist-sessions.db` That's correct, history is stored inside the SQLite...

Agree that it would be desirable for a single user to possess a set of keys, the have some overall control over limits that apply to those keys, and to...