One of my scripts looks up a document (an encrypted ZIP file) by its title. jq extracts the password field I added to that document (via the GUI).
When I tried to decrypt my (local) file with the looked up password, it failed. Turns out, there was a older document with the same title (but with a different password) in 1P Trash.
IMO the CLI should either return all matching entries when looking up by name (instead of UUID) or issue a warning when the lookup is ambiguous. In this special case, one might argue the Trash should not be searched at all (this could also be flagged with something like an --include-trash parameter to be really fancy ;)).
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Yea, I have to say that I'm not crazy about how we handle cases of multiple matches. It almost feels like "op get item" should require an item uuid, but then we'd have to require the vault uuid/name too cause item uuid alone isn't sufficient for uniqueness.
I think we should consider making "op get item" not look in the trash and add a flag to enable looking in the trash.
@dschneller Thanks for the feedback! I'm also not too happy with the behavior. We have an
--include-trashflag on the
op list itemscommand, but not on
op get items. I think it makes sense to ignore trashed items when getting an item by title, but for now I would suggest using the item's UUID for this purpose.
I think I agree with @rickfillion that
get itemshould take a UUID and then we could possibly have an
op search itemthat returns multiple results? Food for thought. Let me know what you think would work for you :)
The UUID based
getwould make things easier technically, of course. If the search call was split out, so I would get a list of one or a few entries matching my criteria -- especially the name, but maybe others -- that would be perfectly fine. In a second step I could then get the item by ID. Also, either provide the
--include-trashor at least surface the information about whether an item is trashed in the result.
Also: Please consider not only
op search itemthen, but also
op search document. One of our most relevant use cases involves uploading a document and adding a password field to it. Currenly
list documentsonly returns IDs, not even the title, let alone any other fields. If need be, I could, of course, add a separate Password item and link that to the document, but that would IMO needlessly increase the number of vault entries.
@dschneller You're absolutely right about that :) We'll keep this feedback in mind going forward. Please let us know of any other gripes you may have!