Overview
When importing from 1Password opvault file using KeePassXC 2.7.5 on macOS 13.4.1, username field has unexpected value in some cases.
Steps to Reproduce
Requirements for the problem to occur are:
- login uses email as username (some platforms only allow email + password combination in their login form, looking at you, discord)
- login has additional
username field for the action username
Expected Behavior
After import, in such a case, it would be expected for the username to be the email address, which indeed resides in the username field in the 1Password login entry.
Actual Behavior
Unexpectedly the value from the top username field in 1P is dropped entirely resulting in data loss or missing data after import. In the example given, the username field of the imported entry shows the actual username and not the email address, which is used in top username field.
Context
It seems the fact that in this scenario, where a login does not allow the actual username, KeePassXC is unable to handle the two different fields which both use username as descriptive name.
One way to workaround this is to change the field name in 1Password holding the actual username to something different. That resolves the issue with having two values for a field called username, which seems to confuse KeePassXC.
However it would still be nice, if this was handled more gracefulyl without dropping information on import. Maybe using suffix numbers for fields that exist twice would be a better option, clearly creates overhead, not sure how best to solve this.
Edit: I just discovered, this is not 100 % reproducible. A similar 1P entry with same structure ended up with the email being indeed used as username and instead dropping the actual username value. So I am not sure what determines, which of the two field values is dropped.
Overview
When importing from 1Password opvault file using KeePassXC 2.7.5 on macOS 13.4.1, username field has unexpected value in some cases.
Steps to Reproduce
Requirements for the problem to occur are:
usernamefield for the action usernameExpected Behavior
After import, in such a case, it would be expected for the username to be the email address, which indeed resides in the username field in the 1Password login entry.
Actual Behavior
Unexpectedly the value from the top
usernamefield in 1P is dropped entirely resulting in data loss or missing data after import. In the example given, the username field of the imported entry shows the actual username and not the email address, which is used in top username field.Context
It seems the fact that in this scenario, where a login does not allow the actual username, KeePassXC is unable to handle the two different fields which both use
usernameas descriptive name.One way to workaround this is to change the field name in 1Password holding the actual username to something different. That resolves the issue with having two values for a field called username, which seems to confuse KeePassXC.
However it would still be nice, if this was handled more gracefulyl without dropping information on import. Maybe using suffix numbers for fields that exist twice would be a better option, clearly creates overhead, not sure how best to solve this.
Edit: I just discovered, this is not 100 % reproducible. A similar 1P entry with same structure ended up with the email being indeed used as username and instead dropping the actual username value. So I am not sure what determines, which of the two field values is dropped.