We’re upgrading the permission management in Play SQL 2.11.

The default permissions

Play SQL inherits the space permissions of Confluence by default. This is very convenient when a spreadsheet belongs to a space: Only users of that space can view it. This is designed to enforce disclosure control: Even if a member of your team shares a Spreadsheet macro on a space with a larger audience, no-one expected that data to become available to so many users, so a change of permissions is required.

Referencing a spreadsheet from another space

First of all, it is possible to insert a spreadsheet from another space using the “recently viewed” list in the macro browser:

The ‘recently viewed’ section lists spreadsheets of other spaces

We’re introducing space permissions for spreadsheets:

• Add groups on top of the space users,
• Or don’t inherit the space users at all and define your own groups for spreadsheet visibility,
• Require membership, so permissions are an intersection of space users and an administration group (such as board members).

Global permissions for advanced control

In the same fashion, permissions can be controlled at a global level and inherited for all spaces. As a result, it is possible to restrict the use of the add-on to a certain category of users.

Database-level Permissions

Some clients prefer to enforce permissions at the database level. They create a SQL user for viewing data, another to edit, another to administer… Since 2.11, Play SQL supports such a configuration.

Play SQL will first check the highest permission of a user, then take the database password of this permission, if defined. Let’s say Alice can edit a space. She wants to view a spreadsheet on the space “Corporate”. Play SQL will lookup the permissions for VIEW on space CORP, notice the highest permission of Alice is EDIT, and thus it will grant her access to the spreadsheet. Play SQL will also use the database password of the EDIT permission to access the data and override the connection to the JNDI datasource using this password.

• In the absence of database password, Play SQL falls back on the main connection.
• Administrators can view all spreadsheets and modify all permissions. When they create a space, they use the database password of ADMIN permission.
• Using this feature requires a JNDI datasource which supports password overriding, such as C3P0. Please see PLAYSQL-135 for more information about this configuration.