I’m looking into creating some applications that would operate on data stored in Grist via REST API.
From what I can see currently there’s a possibility for each user to create 1 API key that the app would use to act as I imagine as this user and within the constraints of that user’s permissions.
I’d suggest expanding that functionality by adding:
- support to multiple API keys creation (like you have it for Github SSH keys) - so that you can revoke access for one connected app/api key while others can still run
- as a next step each API key could have more granular control if it can only read OR read/write to already present cells OR read/write to already present (non-formula) cells/ create new columns (and generally modify the tables) on all the tables user has access to
- as next step the above could be upgraded so that you can select different access levels to different tables/documents
Writing the above I’m not sure if this granular control should be available just to document/workspace owner so that he can set up the permissions freely (as if those api keys we’re “different independent users”) or all users shall be able to set their API keys themselves (within the constraints of their own profiles). Not sure how it would be easier to implement.
Maybe keep current solution for individual users as default (so that they are enabled to do their automations without asking for permission to other person, but document owner could turn that option for them?)
and have additional more granular functionality as I described on owner=“admin level”?