Internal
Public Access
Fix mRemoteNG import failing on entries without a username
The previous username relaxation only touched ProfileDialog's own save-time validation. ProfileRepository::isProfileValid() had the identical "username required for SSH/RDP" check independently, called directly by insertProfile()/updateProfile() -- exactly the path mRemoteNG import uses, since it builds Profile objects and inserts them directly rather than going through the dialog. Every imported SSH/RDP entry without a recorded username was rejected outright. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
@@ -175,6 +175,15 @@ Delivered:
|
||||
cleanly rather than sending Apple auth a blank username. The value is
|
||||
kept on the tab's in-memory profile copy for its lifetime, not written
|
||||
back to the saved profile
|
||||
- The blank-username relaxation above initially only covered
|
||||
`ProfileDialog`'s own save-time validation; `ProfileRepository::
|
||||
isProfileValid()` had the identical "username required for SSH/RDP"
|
||||
check independently, called directly by `insertProfile()`/
|
||||
`updateProfile()` -- which is exactly the path mRemoteNG import uses
|
||||
(it builds `Profile` objects and inserts them directly, never going
|
||||
through the dialog), so importing any SSH/RDP entry without a
|
||||
username still failed outright until this second check was found and
|
||||
removed too
|
||||
- Robustness fix: an unrecognized `FramebufferUpdate` rectangle encoding
|
||||
used to abort the connection generically; `kAnnouncedEncodings` is now
|
||||
the single source of truth for what `SetEncodings` announces and what
|
||||
|
||||
Reference in New Issue
Block a user