Private means it has an owner, and the config does not let
you say who the owner is - plus configured queries should
not be possible to edit or delete in the UI so having an
owner makes even less sense.
You can still make configured queries visible to specific
people using regular view-query permissions.
Split the combined ignored-operation decision test into separate internal-operation and select-statement cases.
Assert the decision reason for each case instead of checking the shared base class, so the tests document why those operations are ignored.
Stop marking sqlite_master and sqlite_schema reads as internal as soon as the SQLite authorizer reports them. The later DDL-aware pass still treats schema catalog access as internal when it accompanies semantic CREATE, ALTER, or DROP operations.
This makes explicit catalog reads in write SQL fall through to the deny-by-default path as unsupported read schema operations, preventing queries from copying private table definitions into writable tables.
Refs https://github.com/simonw/datasette/pull/2749#issuecomment-4559073803
Raw SQL insert and update statements can have broader effects than their SQLite authorizer callbacks reveal. INSERT OR REPLACE and UPDATE OR REPLACE can delete conflicting rows while only surfacing insert or update operations.
Expand table insert and update operations to require insert-row, update-row, and delete-row together. Keep delete operations mapped to delete-row, and update the analysis UI/API to report and evaluate multiple required permissions for a single operation.
Refs https://github.com/simonw/datasette/pull/2749#issuecomment-4559083539
Require view-table permission for reads discovered inside write SQL analysis, including INSERT ... SELECT and CREATE TABLE ... AS SELECT.
Record additional SQLite authorizer callbacks as Operation values so unsupported functions, savepoints, virtual table DDL, and unknown callbacks are denied unless explicitly handled.
view-query is back in the default allow actions now. We have
other mechanisms that work for controlling visibility, and
the fact that queries default to running with the permissions
of the actor makes this safe.
The CSS link in base.html already carries `?{{ app_css_hash }}` so that
browsers refetch when the bundled file changes. The five first-party JS
files shipped with datasette did not. Cache-busting JS the same way
matches the existing CSS pattern and uses the static_hash() helper that
already powers app_css_hash().
Files updated:
- datasette/app.py: expose static_hash as a callable in template context.
- datasette/handle_exception.py: include static_hash in the error-page
template context (mirrors the existing app_css_hash entry there).
- datasette/templates/base.html: hash datasette-manager.js and
navigation-search.js.
- datasette/templates/table.html: hash column-chooser.js, table.js, and
mobile-column-actions.js.
- tests/test_html.py: new test_js_content_hash parametrized across all
five files; existing test_navigation_menu_links updated to expect the
new query string.
Vendored libraries (cm-editor-6.0.1.bundle.js, sql-formatter-2.3.3.min.js,
json-format-highlight-1.0.1.js) already carry a version in the filename
and were left unchanged.
