1P8: Rearranging custom fields?

Hi,

I'm trying out 1Password 8 on Mac, and loving it.

One thing that's bothering me, though: I have a ton of custom fields across all of my items, and 1P7 used to have a way of rearranging fields within a particular section (via this left-hand drag handle on each field row). However, I have not found a way to rearrange custom fields in 1P8: is this a known issue? Is it on the feature roadmap?

Thanks so much,
Caleb

P.S. is there a way to change the data type of a custom field, like I could in 1P7?


1Password Version: 8.7.0 (80700012, on BETA channel)
Extension Version: 2.3.2
OS Version: macOS 12.3

Comments

  • Hi @Caleb531,

    Thanks for taking the time to write in with this.

    However, I have not found a way to rearrange custom fields in 1P8:

    This is on our roadmap to reimplement in 1Password 8 but we don't have an ETA on this.

    ref: IDEA-I-372

    P.S. is there a way to change the data type of a custom field, like I could in 1P7?

    It is not available right now and I'll pass it on to the team as a feature request.

    It's difficult to retain the data when changing the type because changing text into date and then into address types can result in data integrity issues, so it may be best if the user manually create an address field below the field and copy/paste it rather than have 1Password try to guess how it should be retained.

  • volts
    volts
    Community Member

    When the label on a field has been changed, is it possible to see what the datatype on that field is?

  • Ooh, good catch, @volts. For fields that are basically text fields like text, URL, email, and phone, you're right that they become indistinguishable when the label is changed.

    I've noted this in our internal issue for this subject. Thanks!

    ref: dev/core/core#6824

  • volts
    volts
    Community Member

    Do they function differently when they’re those “basically text” fields?

    I’ve been uncertain if the label itself matters, or if only the type changes how they behave.

  • Hey @volts:

    Thanks for following up. There are some differences behind the scenes, but the type set at field creation is currently fixed. To clarify, as it currently stands, if you create a field using the Phone Number type, and then name it Email, behind the scenes it's still considered a phone number field.

    Let me know if that makes sense!

    Jack

  • volts
    volts
    Community Member

    Thanks - yes, that makes sense.

    Is the label solely a display label?
    Or is the label considered when 1Password determines how to fill form fields?

  • The label is considered when filling forms, yes. Whether or not it makes a difference depends on the form and the value of the label. The field type can also be considered when filling forms, but that's the invisible part you can't currently change in the desktop app.

    I'm not sure how much of a difference the field type of these text-like fields makes right now, but I could see a scenario where for email fields (like with the username field) we pop up an autocomplete box that offers other email addresses you've saved in 1Password, for example.

    All that to say, I do think we should allow you to at least be able to see the type of a field so you can determine if it needs to change.

  • BillD
    BillD
    Community Member

    Related to the latter part of the discussion, if not the title of the tread...

    In 1PW7 the field type was changeable. I would like that to be added back to 1PW8. My use case is for "secret questions". I use 1PW to add a field and generate a 3 word password for those questions. In 1PW7 I would then change the field type to text as those answers won't be changing. Now I can't, they stay as password type field.

  • That's an interesting point, @BillD, thanks! I use the password generator the same way, although I just leave them as concealed password fields. I could see why you might want to make them plain text to avoid having to reveal the values. I've added your comments to our internal tracking issue.

This discussion has been closed.