@"Horia.Culea_1P" I'm using 1password to store a JSON document that I need to be able to simply export like it used to work in v1. Amongst all the great features there's no way of simply having a custom-filed object to simulate JSON – all of them are some kind of credential-bast schemas – none of what I want.

You have very fancy stuff like database, API credential, etc. but we can't create our own schema from a scratch, i.e., no password fields and such. As the result, the only way around this is to use a secure note. Which used to work just fine until it all got "improved".

Now I cannot just op item get "${OP_ITEM}" --fields label=notesPlain because apparently "it does the right thing". It doesn't to the right thing for me – that I am very certain of.

I cannot use op read op://path/to/item-field because my item has spaces and special characters and used in numerous docs and the rest of my 1password items follow a convention. I don't want to mess it up just to compensate for this "new and improved API".

And the best part I cannot use (or at least find how to use) 1password API to get the bloody item ID to use it with op read op://path/to/item-field where I cannot use special characters…

I've literally just spent over an hour trying to comprehend these v2 improvements and then double checked if there's an alternative to 1Password because this whole API shinanigans really gets to me for what it's worth.

*I want to be able to return the flipping item's value AS IT IS! *

Right now I need to use a completely different tool jq I've no idea who manages it and if it's actually secure or if it has dependencies. Did you even consider this?

If you want to be smart about this and add quotes, use another format for that, whether it's for CSV or anything else. What I'm getting now is neither human readable or valid or useful.

Thanks for wasting my morning on this. Massive thumbs down!

franklin is it feasible for you to run

op read op://path/to/item-field

?

I mentioned before that we are working on this issue. However, I have recently found out that this is the expected behaviour, and hence I was wrong in considering this a bug.

For example, assuming a field with value "world":

The value stored in the field is "world", if that is encoded to CSV as "world", the quotes are lost because the valid way to decode "world" is to world. So the "" are added ("" is the escaped variant of ") to signal that the " are to be decoded and should be in the output.

Looking forward to hearing from you all about this.

Best,
Horia

I ran into this because I use op to populate .tfvars files for terraform. Here's my workaround:

op item get "${OP_ITEM}" --fields label=notesPlain --format json | jq -r '.value' > "${TF_FILENAME}"

jq returns quoted strings by default for some reason too, but you can use the -r (raw) option to disable that behavior.

kevin_li In some cases we store a json String within a field and running

op item get <item> --fields <field>

with v2 now returns sth like

"{""auths"":""bar""}}"

Yes, I use this to generate a .env file when a new user sets up the repo.
The .env file isn't in version control so it's easier to just generate it on the fly.
op read op://<vault name or ID>/<item name or ID>/notesPlain works for me.

I thought about using the file templates tool but it's more work to test and set that up.

That being said, we do recognize that the current behaviour may not be what you are looking for and are interested in learning more about your use cases to see where we can improve.

Could you tell us a bit more about your workflow? Where are you using the values from 1Password? Are you doing manual commands or feeding the output into a script or another workflow?

@raybb The contents of your notes seem to be a .env format, are you consuming that via a file/library?

franklin What data from the items are you using? Do you need just field data or other data as well? Where and how are you consuming the data (via app, script, other)?

Hey @raybb franklin

We believe that you can achieve the same output behaviour possible with V1 with V2:

Getting the raw value of a single field

v1

op get item <item> --fields <field>

v2

op read op://<vault>/<item>/<field>

Getting multiple values in the csv format

v1

op get item <item> --fields <field1>,<field2> --format csv

v2

op item get <item> --fields <field1>,<field2>

Getting values in the json format

v1

op get item <item> --fields <field>

v2

op item get <item> --fields <field>

We're currently working on this issue, we should be able to push out a fix for this in the next release.
I'll post a comment in the thread once this gets resolved. Thank you once again for reporting!

Hi, would be great to have that fixed.

Read is fine but we're loading the whole item and then extract some fields which currently breaks.

Hey @raybb , thank you for reaching out to us!
I was able to reproduce this, it seems to be indeed a bug. I've filed an internal issue and will take it up with the team during our next team meeting.
In the meantime, there is a new command in CLIv2 that allows you retrieving field values in a more native fashion: op read. Did you already get to give it a try? Running op read op://<vault name or ID>/<item name or ID>/notesPlain should retrieve the correct value.
Let us know if this is helpful for you!
Best,
Horia