You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a Trino database which is made available through connection1. If I create a new schema on this database, I cannot give users permission to access this schema via their role.
When navigating to Settings > List Roles > Edit Record, in the Permissions field I cannot see the new schema, only schema that existed before the creation of connection1.
If I now create a new connection, connection2, which is exactly the same as connection1, I can see the new schema,
Hey @MialLewis! I'm here to help you with bugs, questions, and becoming a contributor. Let's squash some bugs together! 🐛
To set role permissions for a new schema in Apache Superset without creating a new connection, you can use the add_permission_view_menu and add_permission_role methods from the SupersetSecurityManager class. This approach allows you to directly add the necessary permissions to a role.
Here is an example of how you can set schema access permissions for a role:
fromsupersetimportsecurity_managerfromsuperset.models.coreimportDatabasefromsuperset.models.sql_labimportSqlaTable# Define the role name and the schema permissionrole_name="your_role_name"database_name="your_database_name"schema_name="your_schema_name"schema_permission=security_manager.get_schema_perm(database_name, None, schema_name)
# Create the schema permission view menusecurity_manager.add_permission_view_menu("schema_access", schema_permission)
# Find the permission viewpermission_view=security_manager.find_permission_view_menu("schema_access", schema_permission)
# Add the permission to the rolerole=security_manager.find_role(role_name)
security_manager.add_permission_role(role, permission_view)
# Commit the changes to the databasedb.session.commit()
In this example:
Define the role name and the schema permission.
Create the schema permission view menu using add_permission_view_menu.
Find the permission view for the schema access.
Add the permission to the role using add_permission_role.
Commit the changes to the database.
This approach allows you to set role permissions for a new schema without creating a new connection. Additionally, the get_schema_perm method is used to generate the schema permission string, ensuring consistency with how permissions are managed in Superset [1][2][3].
Additionally, Apache Superset handles schema caching through the schema_cache_timeout property. If schema caching is enabled and the cache timeout is set, it could affect the visibility of new schemas in the role permissions. You can force refresh the schema list using the useSchemas hook in superset-frontend/src/hooks/apiResources/schemas.ts:
This hook allows you to force refresh the schema list by calling the refetch method, which can help in making new schemas visible without waiting for the cache to expire [4].
Bug description
I have a Trino database which is made available through
connection1
. If I create a new schema on this database, I cannot give users permission to access this schema via theirrole
.When navigating to
Settings
>List Roles
>Edit Record
, in thePermissions
field I cannot see the new schema, only schema that existed before the creation ofconnection1
.If I now create a new connection,
connection2
, which is exactly the same asconnection1
, I can see the new schema,This bug was discussed last year here: https://lists.apache.org/thread/bqogccdg3wdjkjsgytsqw1ylsmps756v
And now here: https://github.com/konzainc/konza-kube/issues/375
How to reproduce the bug
test_connection_1
(other db's not tested).test_schema
throughSQL Lab
.Settings
>List Roles
>Edit Record
. In the permissions field search fortest_schema
, which will not be foundtest_connection_2
.test_schema
is found throughtest_connection_2
.Screenshots/recordings
No response
Superset version
3.1.3
Python version
3.10
Node version
I don't know
Browser
Firefox
Additional context
No response
Checklist
The text was updated successfully, but these errors were encountered: