Option --fields not working on some items

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

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

```json
"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:
json
{
"id": "",
"type": "STRING"
},


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

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

@"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.

@"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.

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.

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.

@"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.

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!

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?