Confusing behaviour of stored role passwords

[pavish]

Description

• Create multiple databases.
• Open a database, store some passwords (ConfiguredRoles), and create a few collaborators.
• Open another database in the same server, notice the stored passwords already present. This might confuse the user as to why the password configured somewhere else is present here.
• Delete a password and notice that it gets removed from both databases and the user is not made aware of all the consequences while performing the action.

This behaviour makes sense from a logical + backend perspective, where passwords (ConfiguredRoles) are associated with a Server object instead of a Database object.

However our UX is structured in a way that users interact with stored passwords via the Database settings page.

• It is not clear enough from our UX that the passwords are shared between databases in the same server.
• The user does not know which databases are part of the same server and share passwords.
• The consequences of deleting a stored password is not effectively mentioned to the user.

There are a couple ways (out-of-my-mind) to tackle this:

1. Make the stored passwords associated with the Database object (as we currently have Collaborators), or
2. Create a separate page for Servers.

There are pros and cons to either of these approaches. We've had multiple discussions in the past about this and decided to move fast and did not have enough discussions to arrive at a satisfying/easy-to-understand UX behaviour. This issue is to track further discussions and agree on a better UX.

[seancolsen]

This might confuse the user...

Sure. This might be a problem. But I don't think we necessarily need such far reaching changes to solve it.

There are a couple ways to tackle this

I would argue that there's a third approach: keep the structure that we have, but use copy and documentation as a means to iron out any confusion or friction that users might experience. This is the approach that I recall we agreed to follow, and I'm not yet convinced this problem is significant enough to warrant a change to our overall approach here.

We already have some copy to help users understand this behavior:

But we could improve on that copy!

For example we could mention specifically which databases will be affected by the change.

Consider this improved error message:

Remove Stored Password for alice?

Removing this stored password will prevent collaborators assigned to this role from accessing all databases on server mathesar_dev_db:5432.

Specifically:

• For the abc database, the following users will lose access:

  • admin
  • Alice
  • Bob

• For the client_accounts database, the following users will lose access:

  • frank_r
  • Bob

That would be a relatively easy change to make, and I think it would go a long way towards addressing any confusion users might have about the way we've designed this behavior in Mathesar.