Legend

= blocker
= major, acceptable in beta but can't make it into a stable build
= I can live with it

When I start Compass from master, I first get several keychain password requests. Then, after Compass loads and the connect screen is displayed, I get more password requests. This happens also after restarting Compass.

Update: the double round of keychain requests does not happen anymore, but I still see one round of keychain requests every time I open Compass. That's why I put COMPASS-3235 into the sprint.

New Connection in the sidebar remains selected after clicking on a favorite

When selecting existing favorites that were migrated, the SSL configuration does not seem to be set so the connection fails.

For existing favorites that were migrated I don't seem to be able to connect to Atlas, even after setting the SSL configuration manually

If I copy-paste a connection string from the Atlas UI and add the right username/password to it Compass connects successfully. I am not sure if maybe the SSL configuration is not being passed into the connection model. Attaching an example of favorite that was migrated ( favorite-migrated.json ) vs the same favorite re-created by copy-pasting the connect string from Atlas ( favorite-created-brand-new.json ).

Not sure what to do about this, but password is displayed in clear text when switching to connection string view

When I select a favorite and switch to "connection string view" I am actually switched back to "new connection"

When I select a favorite, it is displayed by default in "individual fields" mode. When I click on "Paste connection string", I am switched to creating a new connection.
This could make sense and might also somehow solve the problem above (password in clear text) but the UX feels a bit weird.
There is also a use-case of users wanting to copy the connection string to use e.g. with the shell that we may want to keep in mind.