Trying to add non-custom field to login fails

bepvte

Hi! I used the amazing perl login conversion tool a while ago to convert from enpass to 1password, and because enpass has somewhat interchangeable "username" and "email" fields, some of the entries were not given usernames and instead had emails stored in their entry comments. I was writing a script with the op tool to fix these entries. This conversion is understandable to me, and not why I'm making this post, just trying to avoid the xy problem.

When I get these fields from these converted entries, they have details like this:

"details": {
    "fields": [
      {
        "designation": "password",
        "id": "",
        "name": "password",
        "type": "P",
        "value": "password"
      }
}

No username, even though the template field is set to login, which has a username field (001). This isn't a to me since my script should be adding this field. However, since the field doesn't exist in the entry, op errors with The item doesn't have a "username" field.

I am not sure how to proceed. I would create new entries from the "broken" ones including the new username field, but I would lose some of the password history, as I have been living with this problem for a bit and have updated some entries. I could try running and modifying the conversion script again but I would need to learn perl, and I also have already modified many of the converted entries, which I do not want to overwrite or duplicate.

TLDR: op edit username=username on a login without a username field errors out.

op version 1.0.0

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

felix_1p

That is an unfortunate side effect of how op "determines" fields exist and are settable. It doesn't actually look at the type of the item, it looks at which fields currently exist on the item. Usually, when you create a new item of a specific type, all "default" fields are created on the item, but they are empty (and the other clients usually don't show empty fields).
However in your case those fields literally don't seem to exist and thus op thinks they cannot be set.

I think that we should probably always make the template fields available, even if they don't exist in the actual item data. I will raise that idea with the rest of team.

But to solve your problem, off the top of my head the only solution would be to create a new login item with the correct username and password item, and delete the original item. Basically creating a copy of the original item.

Something like

op create login username="...." password="$(op get item .... --fields password)"

(not sure where you currently get the username from)

bepvte

Thanks for the info. I set that up in my script, but the created test item doesn't have the ainfo field, which I want. I think I'll wait until the op tool has this feature and the ainfo feature. Thanks.

Ben

Understood. Thanks for the update @bepvte. :)

Ben

felix_1p

@bepvte We just released a new version of the command line tool (v1.1.0) which fixes both of these issues:

• You can now always assign to the username and password fields of a Login item, whether they exist or not
• ainfo is set properly populated