Unless you use different Postgres users for each connection (see last section of this page), all users will always be able to query, edit and delete all data from all schemas/spaces. You should also consider that this kind of software allows by definition "SQL Injections", since a core principe of the software is to allow users to write SQL in various places of the application, and therefore it is always possible for an attacker to view, edit and delete data which he doesn't necessarily see through other views.
Users need permissions to create new queries, but, using existing queries, they can use SQL tricks such as filtering (which is done in SQL, hence they can specify their WHERE clause, therefore they can call a stored procedure, etc) to access data from other spaces or schemas.
See our Known limitations.
Spreadsheets and queries are local to a Space, so they inherit the same permissions.
|Space Permissions||Query permission||Spreadsheet permission|
|View||View, sort, filter*||View, sort, filter*|
|Create page||Can edit existing queries, but not save them||Can add and edit spreadsheets|
|Remove page||Can edit and save existing queries||Can remove spreadsheets|
Space Admin (if configured in Play SQL Settings)
or Confluence Admin
|Can edit the datasource||Can edit the datasource|
* Sorting and filtering is done in SQL. It makes it possible to use unfiltered SQL (which is intended), but it also makes it possible to call SQL stored procedures or anything that the SQL connection allows. If you want to ensure no other data is accessed, you need to use the "Space-level permissions" (see below).
When you insert a macro, the "Recently Viewed Spreadsheets" shows spreadsheets from other spaces:
Don't forget that the permissions of the original space apply to the data. Therefore if the audience of the new space doesn't match, you'll have to tune the permissions. See next paragraph.
Since , it is possible to change the permissions of spreadsheets at a space level.
By default, Play SQL creates one schema per space: