Preset Feature Feedback
What is the problem or goal you're trying to solve or accomplish?
When a database connection uses per-user OAuth with impersonation, Preset stores each user's authorization the first time they connect. If that user's role membership later changes on the database side, the stored authorization becomes unusable — the token itself has not expired, but the role it was granted against is no longer available to the user. The user is then permanently blocked from that connection: schema listing fails at connect time with a driver-level error, and there is no way for the user or a workspace admin to clear or refresh the stored authorization for that single connection. The customer's expectation is that a role change on the database side should be recoverable without administrative surgery on the Preset account.
How are you solving it currently?
There is no working workaround. The only available option is deleting the Preset user account and re-inviting them, which also discards their stored authorizations for every other database connection in the workspace — unacceptable for a user with access to multiple connections. Re-granting the original role on the database side is not viable, since the role removal was intentional. The affected user remains blocked.
What is your recommended solution?
A per-connection re-authorization action, so a user (or a workspace admin acting on their behalf) can clear the stored authorization for one database and re-authorize, without affecting authorizations for other connections. The customer additionally suggests that Preset detect connection failures caused by an invalid authorization and reset it automatically, and notes that there is currently no way to authorize against a different role. Note for triage: existing token-expiry handling would not address this case, as the stored token is still valid — only the role backing it has been revoked.
