Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SIP] Adding a more granular write permission for database connections #30957

Open
Hen0k opened this issue Nov 18, 2024 · 2 comments
Open

[SIP] Adding a more granular write permission for database connections #30957

Hen0k opened this issue Nov 18, 2024 · 2 comments
Labels
data:databases Related to database configurations and connections design:proposal Design proposals need:more-info Requires more information from author sip Superset Improvement Proposal

Comments

@Hen0k
Copy link

Hen0k commented Nov 18, 2024

Please make sure you are familiar with the SIP process documented
here. The SIP will be numbered by a committer upon acceptance.

[SIP] Adding a more granular write permission for database connections

Motivation

I want my users to be able to add new google sheets to a pre-existing Google Sheet database I created with a test sheet connection. I am managing this capability with a custom role. It only works if I enable the "Can Write on Database" permission. This allow the user with this role to edit the connection, and add another sheet/table to the database. But this also allows them to edit and delete other database connections.

Proposed Change

I propose a new permission that allowed write access to individual databases instead of allowing edit on all databases connections.

@Hen0k Hen0k added the sip Superset Improvement Proposal label Nov 18, 2024
@dosubot dosubot bot added data:databases Related to database configurations and connections design:proposal Design proposals labels Nov 18, 2024
@rusackas
Copy link
Member

If you want to go this route, it seems plausible, but I think we'd need a little more explanation (i.e. filling out the rest of the SIP template) so we know all the use cases, whether or not this is useful to other database connection types, and if you've explored the alternatives, which might include:
• Having users add additional GSheet connections rather than tweaking a single pre-existing one
• Using an intermediary query engine to deal with administrating rights to add/edit GSheet connections (Trino, Presto, Drill, Shillelagh, etc)

@rusackas rusackas added the need:more-info Requires more information from author label Nov 18, 2024
@Hen0k Hen0k changed the title [SIP] Adding a more granular write permission for database connections (do not add SIP number) [SIP] Adding a more granular write permission for database connections Nov 19, 2024
@Hen0k
Copy link
Author

Hen0k commented Nov 19, 2024

I only have a vague idea about what would need to change for this to work. I am not sure about the other details. That was why I skipped them.

I have tried look at both approaches you suggested. The second one requires introducing new tools to the architecture. And it will be better if I keep that a last option.

I have also enabled Shillelagh and can save public sheets as datasets using sql lab queries. but this only works with public sheets.

And the issue with the first approach is, it doesn't work unless the user has access to all databases.

With the "Can Write on Database" permission, they will be able to create the connection. But they can't access that database right after they create it. This requires an admin to provide them the access. It would be cleaner, if they could have access to the database since they created it. But I am not sure how that would work. That was why I was trying to use a single database for google sheets.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
data:databases Related to database configurations and connections design:proposal Design proposals need:more-info Requires more information from author sip Superset Improvement Proposal
Projects
None yet
Development

No branches or pull requests

2 participants