Forum Discussion

Former Member's avatar
Former Member
5 years ago

[31] How to create multiple fields with same name?

Say that I want to store some account recovery codes and call them exactly that. If I do it manually in 1P app or on 1password.com, it's allowed and subsequent op item get ... returns these fields with different IDs, which is expected:
[{"id":"i5wpspgywwpmwazlopbfglfddu","label":"unnamed","value":"i am so secret"},{"id":"dbq573tes8vrqhvlwbd6jdxqoj","label":"unnamed","value":"so am i"}]
However, if I do an op item edit in a loop and just specify the same path, i.e. ... 'Subsection.Recovery code[password]=...', it'll get overwritten.
Is there a way to force op to generate a random ID for each field that's being updated?


1Password Version: 2.0.0-beta.6
Extension Version: n/a
OS Version: Ubuntu 20.04

5 Replies

  • Former Member's avatar
    Former Member

    I think that would be cool from CLI perspective, but how would that look like in the UI?

  • 1P_Simon's avatar
    1P_Simon
    Icon for 1Password Team rank1Password Team

    I believe the UX friction here originates from the current item structure being key-value pairs of name and value. This requires you to have a name for each field.

    In your use case of recovery codes, the name ("recovery codes") refers to a set of values. There is no separate, different name for each of the recovery codes (although you can work around that by giving each recovery code a number).

    Would it be helpful if we would support a field type that can have multiple values? e.g. a set or list


    op item edit recovery_codes[set[password]]=[code_1,code2...,code10]

  • Former Member's avatar
    Former Member

    Thanks for your input @affectiosus ,

    In that case I think we will leave it as it for the time being, and I'm happy to hear you found a work around with variables in item field names!

  • Former Member's avatar
    Former Member

    No, not mandatory, and in the end I did resort to something similar to your code.

    Regarding the flag, it would probably be a nice addition, but may result in a suboptimal experience depending on the defaults chosen. I.e. personally I'm not currently sure whether I'd prefer adding or overwriting as default behavior.

  • Former Member's avatar
    Former Member

    Hey again @affectiosus ,

    While it is possible to create duplicate (in section and field name) fields in the 1P app and the webapp, it is not currently possible in the CLI.

    The reason is because op item edit <ITEM> command will assume that if a section and field matches, it will be an overwrite instead of creating a new field, which fits most use case but not your specific one. While we don't have any plans to change this currently, I wonder if a flag such as --force-new-fields could work to create new fields even when the field already has a match. What do you think about that?

    Also, is the condition of having identical section/field names mandatory for you? Otherwise I encourage you to consider adding a counter var in your for loop and adding it to the name, like:


    for i in {0..10}; do
    op item edit MyItem totpRecovery$i=$recoveryCode
    done