Using grist-electron for multi-users


I am new to Grist, and like the concept and ease of use very much!

I have tested grist-electron on prems in a multi-user setup on Windows, using symlinks to give access to a common landing.db, grist-electron directory and sqlite databases (grist documents).

This works well technically, in that the workstations can share documents. There is a glitch, though, which is that the data does not synchronize between stations while several users are working at the same time. The data only updates when one starts (or re-starts) the grist-electron app.

Is there a way to get the synchronization to occur?

Note: I am dealing with a project where there will be only one or 2 documents to share. I am looking at that solution (as opposed to using the Docker container solution, where the synchronization is instant), as I can then access the documents from other applications and scripts which also deal with the sqlite databases that Grist uses.

Thanks in advance!

Hmm, multiple instances of Grist modifying the same file may not be a safe arrangement for some kinds of modifications, and you could see various kinds of inconsistencies since each instance of Grist will assume it is “in charge” of the file.

A server would be preferable. While the most supported way to do that is with the Docker container, I believe @Sylvain_Page is or was using grist-electron as a server. There are some settings needed to make this happen:

(specifically the GRIST_ELECTRON_AUTH setting).

The Docker container solution should also allow other tools to read from the documents using SQLite connections.

I confirm I’m still using grist with Electron though I may switch to docker in the future.
On W10 Pro (virtual machine dedicated for this):

  • Information for IT are simple and clear
  • I’m creating more and more documents and other people are smoothly getting used to this new portal.
  • If they need to produce extar stuff from data they copy to xls.
  • Update is Ok, backup as well through file system backup.
    → My main concern will be confidential thing I cannot put in it for the moment but it is not a priority.

I have local directory containing grist-ellectron in which I have this .env file

GRIST_ELECTRON_AUTH=none  # Auth strategy (strict, mixed, or none)

So landing.db and all .grist files are in data subdirectory.
What setting are required to put plugins in local ./plugins subdirectory so that plugin url is
Does grist server serves also static files?

The Grist server will serve only certain static files and directories needed for its operation. I don’t know of a neat way to serve something at /plugin/plugin_name without a code change, although there are other paths that might be possible. What are you trying to achieve? What kind of plugins are you interested in?

My intent is to have self contained electron distribution. Everything (grist-electron.exe, *.grist files and plugins) , contained in one directory and its subdirs.
Default window installation has code in:
"C:\Program Files\grist-electron\grist-electron.exe
data in: Appdata\Roaming and plugins - after first download from web somewhere in Appdata\grist-electron.…
So there is no need to change core part. I work with Quasar framework in electron mode. I usualy have express server in main process and prefer
axios rather then ipc. So no problem, I can start express listening on some port and have intended functionality. I am just experimenting (trying to integrate my electron app . with grist-electron).
I forked grist-electron ,upgraded electron to latest version(v27.1.2) , and for core use main branch (with my translations) and everything works ok. Only Calendar widget is missing.

Got it. The Calendar widget currently needs an environment variable flag (see September 2023 Newsletter - Calendar widget, two new templates, and API endpoint for making SQL queries - #6 by paul-grist) - we’re very close to it activating without the flag, but not quite there yet for grist-electron.