Currently, when a deployment wants to update the DB permissions of a role (db permissions referring to the contents of the permissions.user_role_permissions table), they need to perform a GraphQL query. Completion of this ticket would give them a way to maintain a configuration file that they can have Aerie re-ingest to take in these updates instead.
My proposal for how to fulfill this:
- Create a SQL function exposed on Hasura that executes some
db_user_roles_config.sql file, with that file containing the configuration information for their roles (as in, create these roles if they don't exist and set their permissions to XYZ). This file can either be a file exclusively containing their custom roles, or an extension of the default_user_roles.sql file.
- This SQL function should not automatically delete any roles. If the user wants to remove any roles, they can either directly delete them or include that delete command in their configuration.
- This function/the script should be transaction-wrapped -- we don't want to half-apply the configuration changes if something goes wrong.
Discussion Points:
- Should the migration script try and auto-refresh these updates after running? If it did, that would lead to issues where we add a new permission key, assign it to roles in the migration, and then the refresh removes it. Then again, we have other configuration files we expect the user to update before running migrations.
Currently, when a deployment wants to update the DB permissions of a role (
db permissionsreferring to the contents of thepermissions.user_role_permissionstable), they need to perform a GraphQL query. Completion of this ticket would give them a way to maintain a configuration file that they can have Aerie re-ingest to take in these updates instead.My proposal for how to fulfill this:
db_user_roles_config.sqlfile, with that file containing the configuration information for their roles (as in, create these roles if they don't exist and set their permissions to XYZ). This file can either be a file exclusively containing their custom roles, or an extension of thedefault_user_roles.sqlfile.Discussion Points: