= 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.
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.