Bug 146165 - Hide Tables, Queries and views from data connector
Summary: Hide Tables, Queries and views from data connector
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
7.1.8.1 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-12-10 14:22 UTC by Carl Pettit
Modified: 2022-07-27 10:13 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Carl Pettit 2021-12-10 14:22:30 UTC
Provide option to hide specific tables, queries and views from ODBC/JDBC connectors etc.

As an example, when inserting fields from a database into a Writer document the user can be presented with a daunting number of unrelated data sources to choose from and when they choose the right data source, they may be presented with an equally daunting list of table, queries and views which yield access to potentially sensitive data. If the database designer can select what is visible to the connector, then the user experience would be improved as would security. I believe this is already the case in MySQL.
Comment 1 Robert Großkopf 2021-12-11 07:19:39 UTC
You could hide tables and views by 
Tools → Table Filter…

But this could be reset by anybody who has access to the *.odb-file.

For ODBC/JDBC it will depend on the connection to the database. This will be set by user and password in the database.

The only part you couldn't hide are queries. This is only text content in the *.odb-file. I would prefer to create a separate +.odb-file for people, who should only connect to one query and shouldn't see the other queries.
Comment 2 Carl Pettit 2021-12-11 14:40:07 UTC
I think that the use of another odb file is an unnecessary complication. A quick scan of the Base documentation does not reveal how to do this. My aim is to simplify the user experience rather than improve security. If the table filter could be extended to include views and queries, this would be achieved. The user of Writer would only need to select the right data source and they could be presented with a single query that contains all the fields they need.
Comment 3 Robert Großkopf 2021-12-11 15:20:03 UTC
(In reply to Carl Pettit from comment #2)
> I think that the use of another odb file is an unnecessary complication. 

What is complicated to connect with another *.odb-file to the same database connected through ODBC or JDBC? All views and tables are part of the database. You could hide them all. And you could add one query for the user, who wants to connect with Writer to the data. So you only need to connect the same way as your original *.odb-file connects.

> If the
> table filter could be extended to include views and queries, this would be
> achieved. 

Views are included, because views will be part of the database and will be shown in the tables pane. Only queries won't be hidden.

Let us wait for other people for a comment here.
Comment 4 Alex Thurgood 2022-07-27 10:13:21 UTC
As Robert has pointed out, the table list can already be filtered out.

However, I understand where the OP's request is coming from with regard to user accessibility and control.

When distributing an ODB file, it would be nice to be able to produce a single ODB file for distribution to users, with UI admin control, in which an approved admin could switch off parts of the UI shown to the end user. This could include certain tables, views, forms, etc.

Currently, I don't think that this is possible, and it would require a level of granularity at the application UI level that I don't believe even exists currently. The same criticism has been levelled at other modules of the suite in the past for other use cases, e.g. how can I deactivate module X,Y,Z so that the user doesn't see it, or have access to it.