\r\n\r\n### User Facing Changes\r\n\r\n- Allow creating menu items under table header that triggers JS (instead of opening hrefs per the existing [menu_link](https://docs.datasette.io/en/stable/plugin_hooks.html#menu-links-datasette-actor-request) hook). Items can respond to any column metadata provided by the column header (e.g. label). The proof of concept plugins log data to the console, or copy the column name to clipboard.\r\n- Allow plugins to register UI elements in a panel controller. The parent component handles switching the visibility of active plugins.\r\n - Because native button elements are used, the panel is keyboard-accessible - use tab / shift-tab to cycle through tab options, and `enter` to select.\r\n - There's room to improve the styling, but the focus of this PR is on the API rather than the UX.\r\n\r\n### (plugin) Developer Facing Changes\r\n\r\n- Dispatch a `datasette_init` [CustomEvent](https://developer.mozilla.org/en-US/docs/Web/API/CustomEvent/CustomEvent) when the `datasetteManager` is finished loading.\r\n- Provide `manager.registerPlugin` API for adding new functionality that coordinates with Datasette lifecycle events.\r\n- Provide a `manager.selectors` map of DOM elements that users may want to hook into.\r\n - Updated `table.js` to use refer to these to motivating keeping things in sync\r\n- Allow plugins to register themselves with 2 hooks:\r\n - `makeColumnActions`: Add items to menu in table column headers. Users can provide a `label`, and either `href` or `onClick` with full access to the metadata for the clicked column (name, type, misc. booleans)\r\n - `makeAboveTablePanelConfigs`: Add items to the panel. Each panel has a unique ID (namespaced within that plugin), a render function, and a string label.\r\n\r\nSee [this file](https://github.com/simonw/datasette/blob/2d92b9328022d86505261bcdac419b6ed9cb2236/datasette/static/table-example-plugins.js) for example plugin usage.\r\n\r\n### Core Developer Facing Changes\r\n\r\n- Modified `table.js` to make use of the `datasetteManager` API.\r\n- Added example plugins to the `demos/plugins` folder, and stored the test js in the `statics/` folder\r\n\r\n## Testing\r\n\r\nFor Datasette plugin developers, please see the [alpha-level documentation](https://github.com/simonw/datasette/pull/2052#issuecomment-1510423051) .\r\n\r\nTo run the examples:\r\n\r\n```bash\r\ndatasette serve fixtures.db --plugins-dir=demos/plugins/\r\n```\r\n\r\nOpen local server: `http://127.0.0.1:8001/fixtures/facetable`\r\n\r\nOpen to all feedback on this PR, from API design to variable naming, to what additional hooks might be useful for the future.\r\n\r\nMy focus was more on the general shape of the API for developers, rather than on the UX of the test plugins.\r\n\r\n## Design notes\r\n\r\n- The manager tab panel could be a separate plugin if the implementation is too custom.\r\n- The `makeColumnHeaderItems` benefits from hooking into the logic of `table.js`\r\n- I wanted to offer this to the Datasette core, since the `datasette-manager` would be more powerful if it were connected to lifecycle and JS events that are part of the existing table.js.\r\n- Non-goals:\r\n - Dependency management (for now) - there's no \"build\" step, we don't know when new plugins will be added. While there are some valid use cases (for example, allow multiple plugins to wait for a global leaflet object to be loaded), I don't see enough use-cases to justify doing this yet.\r\n - Enabling single-page-app features - for now, most datasette actions lead to a new page being loaded. SPA development offers some benefits (no page jumping after clicking on a link), but also complexity that doesn't need to be in the core Datasette project.\r\n\r\n## Research Notes\r\n\r\n- Relocated to a [comment](https://github.com/simonw/datasette/pull/2052#issuecomment-1510423215), as this isn't required to review when evaluating the plugin. Including it just for those who are curious.\r\n", "repo": {"value": 107914493, "label": "datasette"}, "type": "pull", "active_lock_reason": null, "performed_via_github_app": null, "reactions": "{\"url\": \"https://api.github.com/repos/simonw/datasette/issues/2052/reactions\", \"total_count\": 0, \"+1\": 0, \"-1\": 0, \"laugh\": 0, \"hooray\": 0, \"confused\": 0, \"heart\": 0, \"rocket\": 0, \"eyes\": 0}", "draft": 0, "state_reason": null}
{"id": 1805076818, "node_id": "I_kwDOBm6k_c5rl0lS", "number": 2102, "title": "API tokens with view-table but not view-database/view-instance cannot access the table", "user": {"value": 9599, "label": "simonw"}, "state": "closed", "locked": 0, "assignee": {"value": 9599, "label": "simonw"}, "milestone": null, "comments": 20, "created_at": "2023-07-14T15:34:27Z", "updated_at": "2023-08-29T16:32:36Z", "closed_at": "2023-08-29T16:32:35Z", "author_association": "OWNER", "pull_request": null, "body": "> Spotted a problem while working on this: if you grant a token access to view table for a specific table but don't also grant view database and view instance permissions, that token is useless.\r\n>\r\n> This was a deliberate design decision in Datasette - it's documented on https://docs.datasette.io/en/1.0a2/authentication.html#access-permissions-in-metadata\r\n>\r\n>> If a user cannot access a specific database, they will not be able to access tables, views or queries within that database. If a user cannot access the instance they will not be able to access any of the databases, tables, views or queries.\r\n>\r\n> I'm now second-guessing if this was a good decision.\r\n\r\n_Originally posted by @simonw in https://github.com/simonw/datasette-auth-tokens/issues/7#issuecomment-1636031702_\r\n ", "repo": {"value": 107914493, "label": "datasette"}, "type": "issue", "active_lock_reason": null, "performed_via_github_app": null, "reactions": "{\"url\": \"https://api.github.com/repos/simonw/datasette/issues/2102/reactions\", \"total_count\": 0, \"+1\": 0, \"-1\": 0, \"laugh\": 0, \"hooray\": 0, \"confused\": 0, \"heart\": 0, \"rocket\": 0, \"eyes\": 0}", "draft": null, "state_reason": "completed"}
{"id": 267759136, "node_id": "MDU6SXNzdWUyNjc3NTkxMzY=", "number": 20, "title": "Config file with support for defining canned queries", "user": {"value": 9599, "label": "simonw"}, "state": "closed", "locked": 0, "assignee": {"value": 9599, "label": "simonw"}, "milestone": {"value": 2949431, "label": "Custom templates edition"}, "comments": 9, "created_at": "2017-10-23T17:53:06Z", "updated_at": "2017-12-05T19:05:35Z", "closed_at": "2017-12-05T17:44:09Z", "author_association": "OWNER", "pull_request": null, "body": "Probably using YAML because then we get support for multiline strings:\r\n\r\n bats:\r\n db: bats.sqlite3\r\n name: \"Bat sightings\"\r\n queries:\r\n specific_row: |\r\n select * from Bats\r\n where a = 1;\r\n", "repo": {"value": 107914493, "label": "datasette"}, "type": "issue", "active_lock_reason": null, "performed_via_github_app": null, "reactions": "{\"url\": \"https://api.github.com/repos/simonw/datasette/issues/20/reactions\", \"total_count\": 0, \"+1\": 0, \"-1\": 0, \"laugh\": 0, \"hooray\": 0, \"confused\": 0, \"heart\": 0, \"rocket\": 0, \"eyes\": 0}", "draft": null, "state_reason": "completed"}
{"id": 324188953, "node_id": "MDU6SXNzdWUzMjQxODg5NTM=", "number": 272, "title": "Port Datasette to ASGI", "user": {"value": 9599, "label": "simonw"}, "state": "closed", "locked": 0, "assignee": {"value": 9599, "label": "simonw"}, "milestone": {"value": 3268330, "label": "Datasette 1.0"}, "comments": 42, "created_at": "2018-05-17T21:16:32Z", "updated_at": "2019-06-24T04:54:15Z", "closed_at": "2019-06-24T03:33:06Z", "author_association": "OWNER", "pull_request": null, "body": "Datasette doesn't take much advantage of Sanic, and I'm increasingly having to work around parts of it because of idiosyncrasies that are specific to Datasette - caring about the exact order of querystring arguments for example.\r\n\r\nSince Datasette is GET-only our needs from a web framework are actually pretty slim.\r\n\r\nThis becomes more important as I expand the plugins #14 framework. Am I sure I want the plugin ecosystem to depend on a Sanic if I might move away from it in the future?\r\n\r\nIf Datasette wasn't all about async/await I would use WSGI, but today it makes more sense to use ASGI. I'd like to be confident that switching to ASGI would still give me the excellent performance that Sanic provides.\r\n\r\nhttps://github.com/django/asgiref/blob/master/specs/asgi.rst", "repo": {"value": 107914493, "label": "datasette"}, "type": "issue", "active_lock_reason": null, "performed_via_github_app": null, "reactions": "{\"url\": \"https://api.github.com/repos/simonw/datasette/issues/272/reactions\", \"total_count\": 1, \"+1\": 1, \"-1\": 0, \"laugh\": 0, \"hooray\": 0, \"confused\": 0, \"heart\": 0, \"rocket\": 0, \"eyes\": 0}", "draft": null, "state_reason": "completed"}
{"id": 456568880, "node_id": "MDU6SXNzdWU0NTY1Njg4ODA=", "number": 509, "title": "Support opening multiple databases with the same stem", "user": {"value": 9599, "label": "simonw"}, "state": "closed", "locked": 0, "assignee": {"value": 9599, "label": "simonw"}, "milestone": {"value": 3268330, "label": "Datasette 1.0"}, "comments": 4, "created_at": "2019-06-15T19:32:00Z", "updated_at": "2020-12-22T20:04:35Z", "closed_at": "2020-12-22T20:04:35Z", "author_association": "OWNER", "pull_request": null, "body": "e.g. I should be able to do this:\r\n\r\n datasette App/data.db Other_App/data.db\r\n\r\nThis currently errors because you can't have two databases taking the `/data` URL path.\r\n\r\nInstead, how about in this particular case assigning the second database `/data-1`?", "repo": {"value": 107914493, "label": "datasette"}, "type": "issue", "active_lock_reason": null, "performed_via_github_app": null, "reactions": "{\"url\": \"https://api.github.com/repos/simonw/datasette/issues/509/reactions\", \"total_count\": 2, \"+1\": 2, \"-1\": 0, \"laugh\": 0, \"hooray\": 0, \"confused\": 0, \"heart\": 0, \"rocket\": 0, \"eyes\": 0}", "draft": null, "state_reason": "completed"}
{"id": 459587155, "node_id": "MDExOlB1bGxSZXF1ZXN0MjkwODk3MTA0", "number": 518, "title": "Port Datasette from Sanic to ASGI + Uvicorn", "user": {"value": 9599, "label": "simonw"}, "state": "closed", "locked": 0, "assignee": {"value": 9599, "label": "simonw"}, "milestone": {"value": 3268330, "label": "Datasette 1.0"}, "comments": 12, "created_at": "2019-06-23T15:18:42Z", "updated_at": "2019-06-24T13:42:50Z", "closed_at": "2019-06-24T03:13:09Z", "author_association": "OWNER", "pull_request": "simonw/datasette/pulls/518", "body": "Most of the code here was fleshed out in comments on #272 (Port Datasette to ASGI) - this pull request will track the final pieces:\r\n\r\n- [x] Update test harness to more correctly simulate the `raw_path` issue\r\n- [x] Use `raw_path` so table names containing `/` can work correctly\r\n- [x] Bug: JSON not served with correct content-type\r\n- [x] Get ?_trace=1 working again\r\n- [x] Replacement for `@app.listener(\"before_server_start\")`\r\n- [x] Bug: `/fixtures/table%2Fwith%2Fslashes.csv?_format=json` downloads as CSV\r\n- [x] Replace Sanic request and response objects with my own classes, so I can remove Sanic dependency\r\n- [x] Final code tidy-up before merging to master", "repo": {"value": 107914493, "label": "datasette"}, "type": "pull", "active_lock_reason": null, "performed_via_github_app": null, "reactions": "{\"url\": \"https://api.github.com/repos/simonw/datasette/issues/518/reactions\", \"total_count\": 0, \"+1\": 0, \"-1\": 0, \"laugh\": 0, \"hooray\": 0, \"confused\": 0, \"heart\": 0, \"rocket\": 0, \"eyes\": 0}", "draft": 0, "state_reason": null}
{"id": 453829910, "node_id": "MDU6SXNzdWU0NTM4Mjk5MTA=", "number": 505, "title": "Add white-space: pre-wrap to SQL create statement", "user": {"value": 9599, "label": "simonw"}, "state": "closed", "locked": 0, "assignee": {"value": 9599, "label": "simonw"}, "milestone": {"value": 4471010, "label": "Datasette 0.29"}, "comments": 0, "created_at": "2019-06-08T19:59:56Z", "updated_at": "2019-07-07T20:26:55Z", "closed_at": "2019-07-07T20:26:55Z", "author_association": "OWNER", "pull_request": null, "body": "Right now a super-long CREATE TABLE statement causes the table page to be even wider than the table itself:\r\n\r\n\r\n\r\nAdding `white-space: pre-wrap` to that `` element is an easy fix:\r\n\r\n\r\n", "repo": {"value": 107914493, "label": "datasette"}, "type": "issue", "active_lock_reason": null, "performed_via_github_app": null, "reactions": "{\"url\": \"https://api.github.com/repos/simonw/datasette/issues/505/reactions\", \"total_count\": 0, \"+1\": 0, \"-1\": 0, \"laugh\": 0, \"hooray\": 0, \"confused\": 0, \"heart\": 0, \"rocket\": 0, \"eyes\": 0}", "draft": null, "state_reason": "completed"}
{"id": 717746043, "node_id": "MDExOlB1bGxSZXF1ZXN0NTAwMjU2NDg1", "number": 1000, "title": "datasette.client internal requests mechanism", "user": {"value": 9599, "label": "simonw"}, "state": "closed", "locked": 0, "assignee": {"value": 9599, "label": "simonw"}, "milestone": {"value": 5971510, "label": "Datasette 0.50"}, "comments": 18, "created_at": "2020-10-08T23:58:25Z", "updated_at": "2020-10-09T16:11:26Z", "closed_at": "2020-10-09T16:11:25Z", "author_association": "OWNER", "pull_request": "simonw/datasette/pulls/1000", "body": "Refs #943", "repo": {"value": 107914493, "label": "datasette"}, "type": "pull", "active_lock_reason": null, "performed_via_github_app": null, "reactions": "{\"url\": \"https://api.github.com/repos/simonw/datasette/issues/1000/reactions\", \"total_count\": 0, \"+1\": 0, \"-1\": 0, \"laugh\": 0, \"hooray\": 0, \"confused\": 0, \"heart\": 0, \"rocket\": 0, \"eyes\": 0}", "draft": 0, "state_reason": null}