Setting a multi-line `notesPlain` value on an edited item

austin

This is sort of two requests in one. I’m currently using op 1.10.3.

1. When I edit a document (op edit document UUID FILE --filename TARGETFILE --title TARGETFILE --account ACCOUNT) any existing metadata (such as notesPlain) is removed. This feels like a bug.
2. If I save the notes separately (op get item UUID --fields notesPlain > notes), then edit the document (see above). I have to add the notes through the MacOS UI as the editing the item to add the notesPlain only gives me the last line of the file (op edit item UUID notesPlain=$(cat notes)).

It would be good if #1 was fixed. It would also be good if I knew how to add a multi-line notes entry on edit item when the item is a document. Suggestions are welcome, but I have tried op encode (I get the encoded value in notesPlain) and have also tried turning it into an otherwise normal JSON field (the newlines remain encoded as \n).

---

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

Justin.Yoon_1P

Hey @austin ,

We have just created an issue to fix the bug mentioned in your first point. Keep your eyes open in the next few releases for the behavior of op edit document to retain the notesPlain field! We will also respond to this thread as well once the bug has been fixed.

For the time being, are there any other fields in the metadata that you feel should also be retained when editing a document? While we are investigating what other fields should be preserved, we'd love to hear your thoughts.

After reading your second point, our team is currently considering adding a --notes flag for a user to specify the notesPlain field on item and document creation.

Thank you for getting these issues on our radar!

austin

I would assume that most of the metadata that can be added to a document should be preserved, but I don’t know which metadata isn’t currently preserved (I have not tested this in depth). The ones that I can think of immediately are tags and notes, and we know that the notes are not currently being preserved.

Out of a belt-and-suspenders approach, I am always specifying --filename and --title; ideally editing a document with a new file would keep the existing filename (that is, just replace the contents of the file) unless a different --filename and/or --title are provided.

Michael_1P

Thanks @austin for your additional feedback! It helps us understand how people are using the command-line tool.

I can see that it'd be frustrating to always have to specify --filename and --title out of an abundance of caution. This is something that we are looking at addressing shortly. ref: dev/b5/op#1488

austin

So I want to clarify something about the notesPlain field; as long as what I have does not have newlines in it, I can easily edit notesPlain. The moment I have newlines in it, only the last line shows up. While it will be wonderful to have a general --notes field that automatically sets that, I want to make sure that I can add a multi-line note with no problem, either by --notes $(cat notes.md) or something with encoding (such that the character pair \n becomes newline or something like that), or maybe with a --notes-json that allows a JSON-encoded string that then gets decoded into the multi-line version.

Justin.Yoon_1P

Hey again @austin,

To parrot @Michael_1P 's sentiment, thanks for the feedback! Regarding specifying --title on edit commands, I do not think that is currently necessary, but as for the --filename it looks like it needs to be specified, otherwise it will get overwritten to the default file name on every edit. I can understand that it could be a frustrating user experience, so I've updated our internal issue for improving the op edit document commands without --filename to retain any previously specified file name.

Regarding editing the notesPlain field, are you currently using a command like op edit item <docItemUUID> notesPlain='my notes\nwith newlines\n' to accomplish this?

I have been testing such commands and noticed that for me, instead of only printing the last line, it will just render the newline chars as string literals.

This is definitely something that we will investigate. Thanks for your clarification.

austin

Regarding editing the notesPlain field, are you currently using a command like op edit item notesPlain='my notes\nwith newlines\n' to accomplish this?

That’s one of two things that happens. If, instead, you do the following:

$ cat >notes <<EOS
my notes
with newlines
EOS
$ op edit item <docItemUUID> notesPlain="$(cat notes)"

Then I’m only seeing with newlines. (I actually use fish, so how certain things work is a little different.)

There’s a Unix convention that could be used here: op edit item UUID notesPlain=@notes where @notes indicates that the contents of notes should be read. Not sure how easy that would be, and it is a little on the obscure side (although heavily used by cURL and a few other tools).

Justin.Yoon_1P

Thanks @austin !

We will look further into detail on using the @ convention when implementing the fix for the 2nd issue.

Justin.Yoon_1P

Hey @austin,

Apologies for the late update, it has been a busy few weeks here at 1Password.

I will start off with the good news - we've fixed the first issue you brought up, look out for it in the next op release!

We looked into the second issue, and found some alternative ways. While we are still considering implementing the @ notation to specify reading the contents for a file, it is not something we can prioritize at this current moment.

We have been doing some testing and found the following ways to get newlines to render correctly that may help suit your use case for now:

# Inline note with newlines
op edit item notesPlain="a note
with newlines"

# Read notes from a file
notes=$(cat notes.md)
op edit item notesPlain=$notes

I hope for the time being that these commands, albeit verbose, can suit your needs.