issue_comments

Landed - documentation is here: https://datasette.readthedocs.io/en/latest/sql_queries.html#writable-canned-queries

See also https://datasette.readthedocs.io/en/latest/authentication.html#permissions-for-canned-queries

There can be a detailed section explaining these different mechanisms on the authentication documentation page.

I imagine they will end up applying to more than just canned queries.

Idea: an "allow_sql" key with a SQL query that gets passed the actor JSON as :actor and can extract the relevant keys from it and return 1 or 0.

I'd really like to support SQL query defined permissions too, mainly to set an example for how plugins could do something similar.

Idea: default is anyone can execute a query.

Or you can specify the following:

```json

{ "databases": { "my-database": { "queries": { "add_twitter_handle": { "sql": "insert into twitter_handles (username) values (:username)", "write": true, "allow": { "id": ["simon"], "role": ["staff"] } } } } } } `` These get matched against the actor JSON. If any of the fields in any of the keys of"allow"` match a key on the actor, the query is allowed.

"id": "*" matches any actor with an id key.

CSRF is done. Last step: figure out a smart way to integrate this with permissions and authentication.

Landed the work so far from #796! Here's the documentation: https://datasette.readthedocs.io/en/latest/sql_queries.html#writable-canned-queries

One challenge with this feature is that it confuses the messaging about what Datasette does somewhat.

Prior to shipping this, Datasette's core value proposition is as a way to publish read-only data.

That changed a little in 0.37 in February when plugins gained the supported ability to execute writes, but there was no way of doing that without a plugin.

With this feature, Datasette becomes a read-write database solution.

I should update the documentation to help explain this. Essentially the message is that Datasette can be used in one of two "modes" - it can be used just for sharing/publishing data, or you can use it to collect and manage data, most likely still in collaboration with plugins for things like authentication.

Some extra thoughts now that this is mostly working:

• "Edit this row" is such an obvious use-case. Could I automatically support row editing where every column except the primary key can be updated?
• It would be useful to be able to link to a query in a way that pre-populates various form fields. The "edit" interface could then be a link that pre-populates the form with all of the existing values.
• Can the redirect URL be configured to include values from the form submission? So you could e.g. add a blog post with a unique slug and then redirect to that URL?

Started a fresh pull request for this in #796 - the one in #703 got a bit untidy.

Here's the new default_permissions.py file I can add this permission check to: https://github.com/simonw/datasette/blob/dfdbdf378aba9afb66666f66b78df2f2069d2595/datasette/default_permissions.py#L1-L7

Idea for the authentication piece: I'll have the canned query code execute the following:

python if await datasette.permission_allowed( request.scope.get("actor"), "execute_query", "canned_query", query_name, default=True ): Then I'll add a default plugin to Datasette which implements that plugin hook, looks at the Datasette metadata for that query, and says "No" if the following (and request.scope["actor"] is empty):

json { "databases": { "my-database": { "queries": { "add_twitter_handle": { "sql": "insert into twitter_handles (username) values (:username)", "write": true, "requires_actor": true } } } } } I think I'll support this too:

json "allowed_actors": ["root"] So you can configure queries to only be available to specific {"id": xxx} actors.

This will be the first time the new permission_allowed mechanism from #699 will be exercised in Datasette core.

Need to figure out what the .json mode for this looks like - and if there's a .csv mode (I think not).

Concept for displaying a success message:

CSS:

```css .success { padding: 1em; border: 1px solid green; background-color: #c7fbc7; }

What should happen when a query has been successfully executed?

That depends on the query. Some queries may wish to redirect to another page. Other queries might want to show a custom message.

There should at least be a default message saying the query has been executed.

I really want the option to use a <textarea> for a specific value.

Idea: metadata syntax like this:

json { "databases": { "my-database": { "queries": { "add_twitter_handle": { "sql": "insert into twitter_handles (username) values (:username)", "write": true, "params": { "username": { "widget": "textarea" } } } } } } } I can ship with some default widgets and provide a plugin hook for registering extra widgets.

This opens up some really exciting possibilities for things like map widgets that let you draw polygons.

YAML for metadata is relevant to this: #713

This feature should include the ability to set a custom redirect URL for after the query has been executed - that way it can be used to build things like "delete this row" which redirect back to the correct table.

This is going to require a pretty full rewrite of the existing canned query logic, which currently shares a codepath with the code that lets you submit a SQL query:

https://github.com/simonw/datasette/blob/298a899e792ebd0cd82a5f01b613c31f19082e51/datasette/views/base.py#L464-L563

This is also going to need me to handle POST form submissions which means I need to be able to parse the form body. I guess that will go in datasette/utils/asgi.py.

It would be useful if this feature supported different types of input - at the most basic level <input type="text"> v.s. <textarea>, but numbers, <select> etc would be useful too. This can be added later as additional metadata.json settings.

I have code for form parsing in asgi-csrf: https://github.com/simonw/asgi-csrf/blob/3fc164a9258ebfa616d4e724fcb102b117277c6e/asgi_csrf.py#L91-L109

Also relevant: this will benefit from an authentication/permissions layer: #699

This is going to need CSRF protection - see https://github.com/simonw/asgi-csrf

By default this will extract the :params using the existing regular expression - which can occasionally break if there is a rogue : in the rest of the query.

To address this: allow an extra optional "params": ["username"] field in metadata which, if available, is used instead of the regular expression extraction.

json { "databases": { "my-database": { "queries": { "add_twitter_handle": { "sql": "insert into twitter_handles (username) values (:username)", "write": true } } } } }