Option --fields not working on some items

davidmartos96

Hello!
I was trying the new CLI version, but I encountered with a strange issue when using the op item get {someId} with the fields option.

To begin with, if I omit the fields option, I can see all the details, but strangely enough, the list of fields displays like this:

Fields:
  password:     somepassword
  password:     somepassword
  rpassword:    somepassword
  source:       some source
  agree:        ✓
  :             Create New Account

As you can see the password field is repeated multiple times, one of them with a leading "r", and the last item label is empty.
No matter which field I choose, e.g. "source", if I run op item get {someId} --fields label=source I get the following in the output: Create New Account

Thanks in advance!

---

1Password Version: 8.6.0
Extension Version: 2.0.0
OS Version: Linux x64 Fedora 35

Horia.Culea_1P

Hey @davidmartos96 ! Thanks for reaching out to us!

Let's try to get to the bottom of this.
For starters, can you let us know what fields you would expect to see in the human-readable output? From the overview you provided and the additional information, I reckon the fields of your item are password, source and agree, is this correct?
Secondly, can you please let us know if the json format of your item (op item get ITEM --format json), as well as the values returned by op read command (op read op://vault-name/item-name/field-name) are correct, and correspond to your expectations? This will help us determine is there is a problem in the item parsing for the human friendly output.
Thirdly, can you please check the item in 1Password for Linux, both in view and in edit mode, and confirm it looks as you'd expect it? This will help us determine if your item got malformed, in any way that could show in other clients as well.
Lastly, have you experienced this problem with any other items?

I am looking forward to hearing from you.

Best,
Horia

davidmartos96

@Horia.Culea_1P Thank you for the reply.
The fields listed in the json format are the following:

"fields": [
    {
      "id": "",
      "type": "STRING",
      "label": "password",
      "value": "*****"
    },
    {
      "id": "",
      "type": "STRING",
      "label": "username"
    },
    {
      "id": "",
      "type": "STRING",
      "label": "fname",
      "value": "*****"
    },
    {
      "id": "",
      "type": "STRING",
      "label": "lname",
      "value": "*****"
    },
    {
      "id": "",
      "type": "STRING",
      "label": "company",
      "value": "*****"
    },
    {
      "id": "username",
      "type": "STRING",
      "purpose": "USERNAME",
      "label": "email",
      "value": "******"
    },
    {
      "id": "password",
      "type": "CONCEALED",
      "purpose": "PASSWORD",
      "label": "password",
      "value": "*******",
      "entropy": 379.5647,
      "password_details": {
        .... etc
      }
    },
    {
      "id": "",
      "type": "STRING",
      "label": "rpassword",
      "value": "*******"
    },
    {
      "id": "",
      "type": "STRING",
      "label": "source",
      "value": "*******"
    },
    {
      "id": "",
      "type": "STRING",
      "label": "agree",
      "value": "✓"
    },
    {
      "id": "",
      "type": "STRING",
      "value": "Create New Account"
    },
    {
      "id": "notesPlain",
      "type": "STRING",
      "purpose": "NOTES",
      "label": "notesPlain"
    }
  ],

If I open the item from the Linux client I can only see "username", "password", "página web" (spanish website) and "website", exactly the ones that have an ID in the json list.
The op read op://vault-name/item-name/field-name works as expected.

Taking a different item as an example I can see that there are fields that could even miss the label property:

{
      "id": "",
      "type": "STRING"
    },

Hope this information is enough to help figuring out the problem.

Horia.Culea_1P

Hello @davidmartos96 , I am sorry for the late response.

From the looks of it, it seems that your item got malformed, somehow, as it does not seem to be an issue from the CLI. Can you please try to access your item in edit mode, via 1Password 8, and let us know if there appear to be any additional fields there?
Similarly, what fields can you see in 1password.com? (different clients do field filtering differently, so, in order to exclude completely that this is a CLI problem, we need to see if other weird stuff happens in other clients as well).

Thanks, looking forward to hearing from you.
Best,
Horia

davidmartos96

@Horia.Culea_1P The item looks ok in edit mode from the 1Password LInux desktop app.

On the desktop app version 8.6.1
username, password and website

On the CLI using op item get {itemId} --format json, I get all the fields posted in the previous comment.
On top of that, if asking for the password field (--fields password), the CLI returns a totally different field, which in this case has the value "Create New Account". This "Create New Account" field is nowhere to be seen in the desktop app nor the browser extension. In 1password.com I can see other fields from my previous comment in the collapsable menu "Web Form Details". In particular the fields that don't have an ID but do have a label in the json output.
But the field with the contents "Create New Account" doesn't appear in any client. In particular this field doesn't have an ID nor a label in the json output, and it's making the CLI misbehave when asking for the password field, returning "Create New Account" instead of the actual password.

davidmartos96

@Horia.Culea_1P Has this been triaged as a bug?
The item took as an example is from a shared vault on a Team account. A colleague on macOS is experiencing the same issue with OP CLI.

Justin.Yoon_1P

Hi there @davidmartos96 ,

We have created an issue for it but have not yet begun investigating it. We will make sure to update or ask any clarifying questions on this thread once investigation is underway.

Justin.Yoon_1P

May I ask which op version (op --version) you are running, and if possible (this is a hard ask) what client the item was initially created in? Also the item's category would be helpful as well.

davidmartos96

@Justin.Yoon_1P Thank you.
I'm running version 2.1.0
The item I believe it was created on the macOS desktop client on version either 6.x or 7.x. It was around 3 years ago.

Justin.Yoon_1P

Hey @davidmartos96 , I've done a bit of preliminary research, and it looks like it may be caused by the fact that this login item has multiple custom fields without ids.

This is interesting, because such item should have been caught during item creation validation, but it is clearly not the case - which I suspect is due to the outdated client that created the item 3 years ago.

I think we can look into fixing this on our end, and I will update you when that update goes live.

Thanks for all the info you've provided so far!

Justin.Yoon_1P

Hey @davidmartos96

We recently released a fix after v2.3.0 that may have fixed this - would you be able to give it a try and let us know?

davidmartos96

@Justin.Yoon_1P It's working now.
Thank you!

Justin.Yoon_1P

Thank you for checking, and happy to hear that @davidmartos96 !