The thing I'm stuck on at the moment is how to implement it such that an allow block for create-table at the root of the metadata will be checked correctly.

Maybe the algorithm when _resolve_metadata_permissions_blocks(datasette, actor, action, resource) is called should do this:

1. If a root permission block matching that action exists, test with that
2. Next, if resource has been passed, check at the database level
3. If the resource included a table/query, check at that level too

So everything is keyed off the incoming action name.

The implementation for this will go here: https://github.com/simonw/datasette/blob/8bf06a76b51bc9ace7cf72cf0cca8f1da7704ea7/datasette/default_permissions.py#L81-L83

Here's the start of the tests (currently marked as xfail):

https://github.com/simonw/datasette/blob/8bf06a76b51bc9ace7cf72cf0cca8f1da7704ea7/tests/test_permissions.py#L652-L689

A bunch of the work for this just landed - in particular the new scheme is now documented (even though it doesn't work yet):

https://docs.datasette.io/en/latest/authentication.html#other-permissions-in-metadata

I may need to consult this file to figure out if the permission that is being checked can act at the database/table/instance level:

https://github.com/simonw/datasette/blob/e539c1c024bc62d88df91d9107cbe37e7f0fe55f/datasette/permissions.py#L1-L19

First draft of documentation: https://datasette--1938.org.readthedocs.build/en/1938/authentication.html#other-permissions-in-metadata

What if you want to grant insert-row to a user for ALL tables in a database, or even for all tables in all databases?

You should be able to do that by putting that in the root permissions: block. Need to figure out how the implementation will handle that.

Also: there are some permissions like view-instance or debug-menu for which putting them at the database or table or query level doesn't actually make any sense.

Ideally the implementation would spot those on startup and refuse to start the server, with a helpful error message.

I'm going to write the documentation for this first.

Thankfully all of the logic for this already lives in just one place:

https://github.com/simonw/datasette/blob/d7e5e3c9f98d194fdfb12f1ecc60ed5b3afbc464/datasette/default_permissions.py#L23-L59

Also, this is another thing which should live in config.yml rather than being crammed into metadata.yml - but I can fix that when I address: - #493

Should I call this key permissions or something else?

Some options:

• permissions
• perms - shorter to type
• allow - I like the word, but might be confusing to change its meaning since we use it already

So the new mechanism needs to extend that to handle all of the other permissions as well.

The simplest design I can think of is this (here illustrated using YAML):

```yaml

instance-level permissions - give every logged in user the debug menu:

permissions: debug-menu: id: * databases: content: # Allow bob to create-table in the content database permissions: create-table: id: bob ```

Current design:

json { "databases": { "private": { "allow": { "id": "*" } } } } This can be applied at the instance, database, table or query level within the nested JSON.

https://docs.datasette.io/en/stable/authentication.html#controlling-access-to-specific-databases

It's actually controlling the following permissions:

• view-instance
• view-database
• view-table
• view-query

There's also a special case for allowing SQL queries,at the instance and database level:

json { "databases": { "mydatabase": { "allow_sql": { "id": "root" } } } }

I keep shipping plugins that set a special hook just so the root user can try them out.

I keep running into a need for this. Every time I create a new plugin that defines a new permission I wish there was a clean way to grant that permission to new users without installing some other permissions plugin.