We are currently evaluating the usage of Play SQL Spreadsheets for Confluence. During our test phase we ran into some unexpected behaviour, which we would like to understand better.
Our setup of Play SQL Spreadsheets has one postgresql database and one postgresql user for each confluence space we want to use the plugin with. We plan to use the plugin for data, for which the storage in a database would be preferable, but we need to make sure it is not accessible for everyone who has access to the confluence instance in general.
A very specific, but important use case is the collection of data within one confluence space A and the reporting of an aggregated version of the data in confluence space B. As outlined above, space A has a database user A and own postgresql database A, whereas space B has also a database user B and database B.
Our plan was to aggregate the data as required in space A and then make those tables with only aggregated data available for user B on our postgresql instance.
This works to a certain extent, so that confluence users which can access space A and B see Play SQL graphs and tables based on the described database tables in space B. Confluence users, however, which are only allowed to access space B, cannot see Play SQL graphs and tables based on data stored in space A.
Is this behaviour desired / enforced by Play SQL Spreadsheets? And what would be a potential technical solution to enable us using the plugin in this way?
Any insight would be very welcome. Thank you in advance.
It’s very important to have access to the workflow process from anywhere. Especially if you manage the work of others. There is no difference whether you’re out of office, or drive a ca...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event